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 Chromium, Playwright CLI, TigerVNC, Openbox, and a WebSocket bridge dependency. These are installed at build time; claiming a sandbox does not start a desktop or download a browser. Applications such as Sandpi start the desktop on demand and expose an authenticated viewer.

Run the headed browser as the dedicated sandbox-browser user, retaining Chromium'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.

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 ephemeral and is excluded from checkpoints. 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#