Skip to main content
The OpenCode E2B workspace plugin registers an e2b workspace type in OpenCode. OpenCode keeps running on your machine. Each workspace is an E2B sandbox that runs a remote OpenCode server on a copy of your project. You can start a session inside the sandbox, or move an existing local session into it with /warp.
The plugin builds on OpenCode’s experimental workspace API. See Known limitations before relying on it.

Prerequisites

Install

Add the plugin to your OpenCode config. The second element of the tuple is optional and holds the plugin options.
opencode.json
Start OpenCode with your E2B API key and the workspace flag.

Use

1

Create a workspace

In OpenCode, run /warp and choose E2B Sandbox. The plugin builds a sandbox template for your project, uploads a snapshot of the project, and starts a remote OpenCode server. The first build for a project takes one to two minutes. Later workspaces reuse the template.
2

Work inside the sandbox

Send a prompt. The agent runs inside the sandbox, on the sandbox copy of your project. The workspace is named after your branch, for example e2b-main.
3

Move a session

From an existing local session, run /warp and pick the workspace. OpenCode moves the session history into the sandbox. To move a session back to your machine, run /warp and choose None. OpenCode then offers to move the sandbox’s file changes with it: the diff of what the agent changed is applied to your project as a patch. Your local history is untouched, and commits made inside the sandbox do not travel back. Your project must be a git repository root for the patch to apply.
4

Start a new session

/new starts a new local session. Run /warp again to put it in the sandbox.

How it works

The plugin layers a small workspace template on top of the published E2B template e2b/opencode:v<version>, where <version> matches your local OpenCode. If that template is not available, the plugin builds its own base from the configured Node image and installs the same OpenCode version. Managed templates use the opencode-e2b- alias prefix, and a best-effort cleanup removes old ones. Inside the sandbox, the project lives at the same path as on your host, and the remote OpenCode server runs as the sandbox user. OpenCode resolves a session directory on both the host and the sandbox, so a shared path is what lets a warped session work on both sides. The plugin returns the workspace only after the remote server answers on its health and sync endpoints.

Options

bootstrap.installCommand and bootstrap.startCommand from older configs are accepted but ignored: the template installs OpenCode and starts the server.

Known limitations

Experimental foundation

The plugin uses the experimental_workspace API of OpenCode. You must set OPENCODE_EXPERIMENTAL_WORKSPACES=true. OpenCode can change this API without notice.

macOS and Linux hosts only

The sandbox stores the project at the same path as the host, which is what makes a session directory valid on both machines. A Windows path cannot exist in the sandbox, so on Windows the project lives at /home/user/project instead and the host cannot open that path. Workspaces created on Windows are not supported.

A sandbox does not survive inactivity

E2B destroys a sandbox once sandboxTimeoutMs passes without any request from OpenCode. The default is 1 hour. The workspace then shows as unavailable and you must create it again. For long breaks, set a higher sandboxTimeoutMs.

Warp of a session with history can fail

A warp of a new session is reliable. A warp of a session with existing messages can fail with a sync error (“sequence mismatch”). If this happens, try the warp again, or start the session inside the workspace.

Run OpenCode in a sandbox

The other direction: run the OpenCode agent inside an E2B sandbox

Sandbox persistence

Pause and resume sandboxes to keep state beyond the timeout

Templates

How E2B templates are built and cached