Coding Agents

Use a Sandbox0 sandbox as a persistent coding workspace with isolated command execution, file APIs, network policy, and rootfs snapshots.

Workspace Lifecycle#

1. Claim the coding-agent template.
2. Clone or create the repository under /workspace.
3. Pause the sandbox when it is idle; resume restores the writable rootfs.
4. Create a named rootfs snapshot at a useful milestone.
5. Claim additional sandboxes with that snapshot ID for parallel tasks.

bash
SANDBOX_ID="$(
    s0 -o json sandbox create --template coding-agent \
        | jq -r '.ID // .id'
)"

s0 sandbox exec "$SANDBOX_ID" -- \
    sh -lc 'git clone https://github.com/example/repo /workspace/repo'

Use the SDK file and command helpers when the agent needs structured reads, writes, directory listings, or long-running command contexts.

Shared Browser#

The template includes sandbox0-browser, Google Chrome Stable, Playwright CLI, TigerVNC, Openbox, and a built-in noVNC viewer. Start the helper in a supervised session and open a Private Preview for port 6080 to share the browser with a human. Dependencies are installed at image build time; claiming a sandbox does not start the desktop. Applications such as Sandpi use the same helper with their own authenticated viewer.

See Shared Browser for the Quickstart and how it differs from Steel Browser. Existing sandboxes need an explicit upgrade if sandbox0-browser is not installed.

Run the headed browser as the dedicated sandbox-browser user, retaining Chrome's process sandbox. A human viewer and Playwright CLI can share the same browser through a loopback CDP endpoint. Keep the browser profile on the persistent RootFS and restrict the desktop ingress to authorized viewers; never publish CDP directly. Pause/resume preserves profile files. A filesystem-only resume starts new browser and desktop processes; an explicit memory checkpoint can retain supported process state; viewer connections still need to reconnect.

For an end-to-end example, read how Sandpi lets humans and agents share one browser.

Template Updates#

The Update Coding Agent Template workflow refreshes the npm latest stable versions of Codex, Claude Code, OpenCode, Pi, and Playwright CLI every three UTC days. A daily schedule checks UTC epoch days, so the interval does not reset at month boundaries. Maintainers can also run it manually.

Chrome Stable is installed from Google's official package for each native architecture during the image build. Playwright CLI attaches to the running browser through CDP instead of downloading its own browser executable.

The workflow records exact dependency versions, the lockfile, and the package inventory in a shared build artifact and release assets without bypassing main branch protection. Both native amd64 and arm64 image builds must pass the Dockerfile's CLI startup checks before an immutable, uniquely tagged release receipt is published. The infrastructure refresh workflow consumes completed receipts and updates the coding-agent template image pin used by Sandpi. Infrastructure CI prepares the image using the active region's RootFS importer policy, waits for attested artifacts, and updates Sandpi's configured team-owned coding-agent template in ali-ue1. Failed imports leave the previous template unchanged. Updating a public template alone does not replace a team override.

Updating the template affects new sandboxes after deployment. Existing sandbox RootFS generations retain their installed harness versions across pause/resume; they require an explicit in-place upgrade or paused RootFS rebase.

Durability Boundary#

The writable rootfs is tied to the sandbox identity. Pause/resume preserves it; deleting the sandbox removes it. Named rootfs snapshots are independent restore points that support restore, claim-time initialization, and fork workflows.

/tmp remains a runtime tmpfs and is excluded from RootFS checkpoints. An explicit memory checkpoint can retain supported tmpfs state, but a default filesystem-only pause discards it. Keep repositories, dependency environments, agent memory, and generated artifacts under ordinary writable RootFS paths such as /workspace or /var/tmp.

Parallel Tasks#

After repository setup and dependency installation, create a rootfs snapshot and claim one sandbox per task from the same snapshot. Each claim receives an isolated Copy-on-Write rootfs, so task changes do not mutate the source snapshot or sibling sandboxes.

See Snapshot And Restore for SDK and HTTP examples.

Next Steps#