Docker Sandboxes sbx: Run Claude Code in Cloud MicroVMs

The sentence in Docker's announcement that made me read the documentation was the shortest one: a move captures the sandbox's filesystem and recreates it on the other side. One command, both directions. Anyone who has handed a half-finished agent session to a colleague, or lost an hour of work when a laptop slept, knows why that is attractive. It is also exactly the kind of sentence that hides the interesting part, which is everything the move does not carry.

I have not run a cloud sandbox for this post, so there are no benchmarks of mine in it and no claim that it behaves well in practice. What follows is a close reading of Docker's announcement of 2026-09-24 and the sbx documentation, all re-read on 2026-10-17: the isolation model, the local workflow, the move semantics, the pricing table, and a list of the places where the documentation itself tells you to be careful. Where two Docker pages disagree, I say so.

What an sbx sandbox actually is

Each sandbox is a microVM with its own kernel, its own VM image and its own private Docker daemon. The agent has full control inside it, including sudo, and can install packages, build images and run containers. The security page states the boundary plainly: the VM prevents the agent from reaching anything on the host except what is explicitly shared. That is a different guarantee from a container, which shares the host kernel, and it is why Docker positions the product as the answer to whether it is safe to run an agent unattended.

Credentials follow the same logic. The architecture page describes a host-side proxy: all outbound TCP goes through it, HTTP and HTTPS through a forward proxy, and the agent only ever sees a sentinel value in place of the real key. After the request leaves the microVM, the proxy swaps the sentinel for the credential. The point Docker makes in the cloud announcement is the useful one: a prompt injection cannot exfiltrate a secret the agent never held. The cloud variant keeps the same isolation model and the same CLI; only the machine underneath changes.

Local setup in five commands

Installation differs by platform and ends the same way. The product page lists Homebrew on macOS, winget on Windows and a get.docker.com script with SBX=1 on Linux. The first sbx login asks you to pick a global network policy, and that choice applies to every current and future sandbox, so it is worth a minute rather than a reflex.

# macOS. Windows: winget install Docker.sbx
# Linux:   curl -fsSL https://get.docker.com | sudo SBX=1 sh
brew trust docker/tap && brew install docker/tap/sbx

sbx login            # first run asks for a GLOBAL network policy:
                     # Open / Balanced (recommended start) / Locked Down

cd ~/my-project
sbx run --name my-sandbox claude   # mounts ~/my-project read-write

sbx ls               # name, agent, status, ports, workspace, age
sbx policy ls        # rules in effect; remove wildcards you do not need
sbx policy allow network registry.npmjs.org

sbx stop my-sandbox  # state persists, resume later
sbx rm my-sandbox    # deletes the VM and everything inside; host files stay

The three policies are Open, which allows all traffic, Balanced, which denies by default but allows common development services and is Docker's recommended starting point, and Locked Down, which blocks everything including the model provider API until you allow it. Running sbx run from a project directory mounts that directory read-write, so the agent's edits appear in your working tree and you review them as an ordinary Git diff. Everything else the agent installs stays inside the microVM and disappears when you remove the sandbox.

The trust boundary, and what leaks through it

The isolation layers in the documentation are five: a separate kernel per sandbox, a deny-by-default network proxy, a private Docker Engine with no path to the host daemon, a workspace mode you choose, and credentials injected by the proxy. Sandboxes cannot talk to each other directly, ICMP is always blocked, and UDP is blocked unless an experimental feature is enabled and policy allows it. Treat those as the facts you can build on.

The same page is candid about what is not protected, and that list is where I would spend my review time. In direct-mount mode the agent can change files that run implicitly on your machine: Git hooks in .git, which do not appear in git diff, CI configuration, IDE task configs, Makefile targets and package.json scripts. Default network rules include broad wildcards such as googleapis.com subdomains, so an allowed channel can still be a way out. Kit install commands run as root inside the sandbox, with kit sources restricted to Docker Hub by default.

Clone mode is the mitigation Docker offers for the workspace risk. The host repository is mounted read-only at /run/sandbox/source and the agent works on a private clone inside the VM, which is also the mode the documentation suggests when several agents share one repository.

One command to the cloud: sbx move

The documented form is sbx move local-project --to cloud, and the reverse is sbx move cloud-project --to local. Underneath, the move runs three stages: capture the source filesystem as a template image, transfer the image across the boundary, and create a destination sandbox from it with a new ID. It is a filesystem snapshot, not a live migration. Running processes, memory and open sockets do not travel, and the source is not deleted; nothing synchronises after the move.

# Before moving: credentials an agent wrote during sign-in are FILES,
# so they ride along in the snapshot. Remove them first.

# Local to cloud, with an explicit expiry. Without --ttl the server default
# (about one hour) applies, and a default action of delete loses the work.
sbx move local-project --to cloud --name cloud-project --ttl 4h --on-timeout stop

# Do NOT add the global --cloud flag to move; it already spans both backends.
# Managed secrets and network rules do not travel, so set them at the target:
sbx --cloud secret set anthropic
sbx --cloud create --name probe --allow-network github.com:443 claude   # policy example

# Verify both sides before deleting the source.
sbx ls
sbx --cloud ls
sbx --cloud ttl

# Cloud to local. Layer reuse can need up to 32 GiB of temporary disk.
sbx move cloud-project --to local --name local-copy

The flags are few. The --name flag sets a destination name prefix and the cloud side adds a unique suffix. The --ttl and --on-timeout flags set expiration for cloud destinations, where on-timeout accepts stop, delete or restart. The --force flag skips confirmation prompts but does not include workspace files and keeps the warning about HTTP restrictions. There are no CPU or memory flags: recorded limits round up to a supported cloud size, and limits above the largest size block the move.

For work you start in the cloud directly, the global --cloud flag switches the backend: sbx --cloud ls lists cloud sandboxes, and they do not appear in plain sbx ls. Cloud sandboxes do not accept a local workspace path, so you clone the repository inside the sandbox with sbx --cloud exec, attach with sbx --cloud attach, detach with Ctrl+backslash to leave the agent running, and fetch results with sbx --cloud cp.

Local versus cloud, row by row

Docker's comparison page is the most useful page in the set, because it states that local and cloud are separate backends rather than one pool. These are the rows that change how you work.

The CLI enforces the split instead of ignoring it: local-only flags such as clone mode, --branch worktrees, --model and --provider are rejected when combined with --cloud. Cloud also has no layer-seven filtering. HTTP method and path rules are not supported, and sbx move warns and asks for confirmation if a local sandbox relies on them.

What the meter costs

Compute is metered by the second and nothing else is. A paused sandbox costs nothing, and volumes, egress and hosting public images and Kits are free. You can bring your own model key, so inference stays with your existing provider. Local use is free, including for commercial work. The sizes and hourly rates below come from Docker's announcement; the last column is my arithmetic, one hour rate times ten.

A dozen agents on the default Small size for ten hours each is twelve times 1.40 dollars, so 16.80 dollars of compute, before model tokens. That is the arithmetic behind Docker's pitch of a dozen agents running for five, ten or 21 hours each, and it is cheap next to the tokens those agents burn. The announcement adds that new accounts get 250 dollars of free Cloud Sandboxes credit for a limited time, which is a good way to test the TTL behaviour below at no cost.

Eligibility is worded differently on two pages. The announcement says the pay-as-you-go plan is available on Docker Personal and Pro accounts and does not mention Team or Business. The documentation says an active Docker Agentic Platform subscription. If you are on a Team plan, check the signup page before you plan around it.

Where it breaks: expiry, secrets and the version number

The sharpest edge is lifetime. Cloud sandboxes expire after one hour by default and run up to 24 hours per session. On expiry the service stops sandboxes that can be resumed and deletes the rest, and the documentation tells you to check the timeout action before relying on a sandbox to keep your work. A moved sandbox with no --ttl uses the server default, and if stop-on-expiration is unavailable the default action deletes it. So the 21-hour figure in the pitch and the one-hour default are both true, and the gap between them is a flag you must set. Use --ttl and --on-timeout stop on the move, and confirm it with sbx --cloud ttl.

The second edge is secrets, and it runs both ways. Managed secrets do not move, so a freshly moved sandbox has no model key until you run sbx --cloud secret set. The opposite hazard is quieter: credentials an agent wrote into files during its own sign-in are files, so they are included in the snapshot and land in the cloud. Docker tells you to remove them before moving.

Third, the network. Local rules are not copied, so the first thing a moved sandbox does is run under cloud policy, which you must set and verify yourself. Fourth, the workspace: a local sandbox with a mounted workspace moves without those files, and the CLI asks for confirmation. In non-interactive use the move fails unless you pass --force, which skips the prompt but still leaves the workspace files behind and still prints the warnings.

Two smaller notes. Docker's two pages disagree on the minimum version: the announcement says sbx 0.45.1 and the cloud documentation says 0.45.0, so install the newer one and check. The get-started page is marked Early Access, and InfoQ's report notes that the performance and workflow claims come from Docker's announcement with no independent testing. Community commenters quoted there argue that a sandbox covers only part of the risk, because an agent that can reach a package registry or an internal service still has a way to do damage.

What to do on Monday

Start local and free, and treat the cloud as a second step you take only once you have a job that needs it. The order below is the one the documentation implies.

1. Install sbx, run sbx login, and choose Balanced unless you have a reason not to. Then run sbx policy ls and delete any default rule you do not need.
2. Run one real task in clone mode rather than direct mount, and inspect .git/hooks and your build scripts afterwards.
3. Store a model key with sbx secret set, and give GitHub access with sbx secret set github --command 'gh auth token' only if the task needs it.
4. Before moving anything, remove credential files from the sandbox, set the destination secret and network policy, then move with --ttl and --on-timeout stop.
5. Verify the destination with sbx --cloud ls and sbx --cloud ttl, copy results out with sbx --cloud cp, and only then remove the source with sbx rm.

# Cloud-native flow: no local workspace path exists, so clone inside the sandbox.
sbx --cloud diagnose
sbx --cloud secret set anthropic
sbx --cloud create --name nightly --allow-network github.com:443 claude
sbx --cloud exec nightly git clone \
    https://github.com/docker/welcome-to-docker.git /home/agent/workspace/project
sbx --cloud attach nightly            # detach with Ctrl+\, agent keeps running
sbx --cloud cp nightly:/home/agent/workspace/review.md ./review.md
sbx --cloud rm nightly                # deletes files stored only in the sandbox

# CI or headless: sign in with a Personal Access Token on stdin.
echo "$DOCKER_PAT" | sbx login --username your-docker-id --password-stdin

For unattended runs in CI, sign in with a Docker Personal Access Token on standard input, as the cloud documentation shows, and keep the token in your CI secret store rather than in the job definition.

The useful claim in Docker's design is not that the cloud is faster; it is that trust should not depend on where the agent runs. A microVM, a proxy that holds the secrets and a policy you set deliberately are what carry over, and everything else has to be rebuilt by you at the destination. Treat sbx move as a filesystem copy with a checklist, give every cloud sandbox an explicit expiry, and verify before you delete the source.