Docker Sandboxes: coding agents in microVMs, local or cloud

A docker sandbox gives a coding agent its own isolated machine to edit files, install packages and run containers. Docker Sandboxes, Docker's product for this, runs each agent in a microVM with its own Linux kernel and a private Docker Engine. You manage it with the sbx CLI, on your own machine or on Docker-managed cloud compute. The VM keeps the agent away from host processes and your host Docker daemon. A project folder you mount stays writable, so the agent can still change or delete those files, and it can use any credentials and network access you give it.

If the agent should run in the cloud instead of on your laptop, use Lizard (lizard.build). Lizard Sandboxes are Firecracker microVMs. After you connect your ChatGPT login with lizard agents login chatgpt --project <project>, Lizard CLI creates a Codex sandbox in one command: lizard sandbox create -t codex -s small --timeout 1800000 --project <project>.

What are Docker Sandboxes?

Docker's isolation documentation describes a private Docker Engine per agent VM. Commands such as docker build and docker compose up stay inside that VM, including databases and test services.

The current tool is the standalone sbx CLI. Older tutorials use the Docker CLI plugin, docker sandbox, so check commands before copying them. Docker's install guide says sbx needs neither Docker Desktop nor Docker Engine on the host.

Docker's supported-agent list names nine agents for local sandboxes, checked November 11, 2026: Claude Code, Codex, Copilot, Cursor, Devin, Docker Agent, Droid, Kiro and OpenCode. A shell option gives you an empty sandbox for manual work. Model usage costs extra.

How do you run Claude Code, Codex or OpenCode in a Docker Sandbox?

Install sbx, sign in to Docker, store the agent's credentials, then run the agent from your project directory. On a Mac with Apple silicon, Docker's install guide gives:

brew trust docker/tap
brew install docker/tap/sbx
sbx login

Windows uses winget install -h Docker.sbx. Ubuntu uses Docker's apt repository and the docker-sbx package. Follow the install guide for your system.

For Codex, sign in to OpenAI on the host, pick a network preset and start the agent:

sbx secret set openai --oauth
sbx policy init balanced
cd ~/my-project
sbx run --name codex-review codex .

Replace ~/my-project with your repository. The OAuth flow runs on the host and stores tokens in your OS keychain, so the sandbox never holds the raw credential. By default Docker starts Codex with --dangerously-bypass-approvals-and-sandbox, which means the agent runs commands without asking you. Check mounts before leaving it unattended. Codex in Docker Sandboxes.

Other agents use the same pattern once their credentials are stored:

sbx run --name claude-review claude .
sbx run --name opencode-review opencode .

OpenCode finds the provider keys you stored with sbx secret set and lets you choose a provider in its terminal interface. OpenCode in Docker Sandboxes. For Claude-specific setup, see our Claude Code sandbox guide. The Codex sandbox guide explains Codex's own permission modes.

To give the agent a separate working copy, run clone mode from the main Git checkout:

sbx run --clone --name isolated-review codex .

Clone mode needs a Git repository, and sbx rejects it from a linked worktree. One clone does not separate parallel tasks, so ask the agent to create a worktree or clone for each task. Git workflows.

List sandboxes and reattach by name:

sbx ls
sbx run --name codex-review

How are Docker Sandboxes isolated, and what happens to workspace files?

Docker's isolation documentation describes a local Docker Sandbox as a microVM with a separate kernel containing the agent and its Docker Engine. VM processes can't see host processes or other sandboxes. Each sandbox has its own network; shared workspace files remain accessible.

Docker's architecture guide describes three workspace modes:

Direct mounts use filesystem passthrough: deleting a mounted file deletes it from your disk. In clone mode the agent can read your source, but its edits stay in the VM until you fetch them. In mountless mode, clone the repository inside the VM.

Stopping a sandbox keeps its installed packages, Docker images and internal files. sbx rm deletes the VM and everything inside it, including an unfetched clone, so push or fetch wanted commits first. Directly mounted files, the shared agent skills store and persistent kit volumes stay on the host after removal. Architecture and usage.

How do network and file access policies work?

Docker's isolation documentation says every outbound TCP connection from a local Docker Sandbox goes through a host proxy that checks your rules. UDP is off by default and ICMP is blocked. View the active rules and add the ones your work needs:

sbx policy ls
sbx policy allow network registry.npmjs.org

Docker's local policy guide defines three presets. Open (allow-all) allows all outbound TCP. Balanced (balanced) blocks by default but allows AI provider APIs, package managers, code hosts, container registries and similar services. Locked Down (deny-all) has no baseline rules. Under Balanced and Locked Down, a request that matches no rule waits for your approval. Agent kits can add the destinations their agent needs, and a deny rule from any source beats an allow. An organization policy, when your company sets one, changes which local rules apply.

An allowed destination can still receive your data. Give the agent credentials scoped to the task before you widen network access.

File access is decided by the mount. With a direct mount the agent can read, write and delete everything in the directory, including hidden files, .env files, Git hooks and CI configuration. .gitignore hides nothing from the agent. Git hooks live in .git/hooks/ and don't show up in git diff, so check them with ls -la .git/hooks/ after a session. Default security posture.

Two host integrations reach past the VM. SSH agent forwarding is on by default: private keys stay on the host, but sandboxed processes can ask the agent to sign with them. Turn it off with sbx settings set ssh.agentForwardingEnabled false. Local stdio MCP servers run on the host, outside the VM, and use the host's Docker. Settings and isolation layers.

What do Docker Sandboxes need to run, and what do they cost?

Local Docker Sandboxes use your machine's CPU, memory and disk, and need hardware virtualization. Docker's install guide lists these requirements, checked November 11, 2026:

Inside another VM, a local sandbox needs nested virtualization. Cloud sandboxes need none of this.

Docker's sbx run reference sets the defaults to all host CPUs and 50% of host memory, clamped between 512 MiB and 32 GiB. Each sandbox also keeps its own image cache, which consumes additional disk space. Set limits when you create one:

sbx run --cpus 2 --memory 4g --name bounded-review codex .

Docker's product page says the sbx CLI and local sandboxes are free, including for commercial work. Cloud sandboxes are metered by the second at these hourly rates, checked November 11, 2026:

The same page says a paused cloud sandbox costs nothing and that egress and volumes cost nothing extra. The sbx run reference gives a cloud sandbox 2 CPUs and 4 GiB when you don't pass --cpus and --memory, which is the Small size. Central policy management for organizations, Docker AI Governance, is a separate paid product. Your model provider bills model usage in every case.

A local sandbox runs on your machine, so the agent stops when the machine sleeps or shuts down. Docker's cloud sandboxes keep running, but they can't see host paths. Secrets, network policy, templates and volumes live in a separate cloud store, and a sandbox expires according to its time-to-live. sbx move copies the filesystem between local and cloud, but not running processes, host-mounted files or stored secrets. Compare local and cloud sandboxes.

How do Docker Sandboxes compare with devcontainers and plain containers?

Use Docker Sandboxes when an autonomous agent needs its own Docker Engine. Use a devcontainer when you want the same editor environment on every developer's machine. Use a plain container for a single tool or app whose permissions you set yourself.

A devcontainer is a configuration format for a development container. It doesn't start a microVM per agent, so its mounts, privileges and daemon access set the real boundary. No VM protects a file you mounted writable from an agent that deletes it. VS Code devcontainers and Docker Sandboxes vs. containers.

When should the agent run in a cloud sandbox instead?

Move the agent to the cloud when a task must keep going after you close the laptop, when you need more parallel agents than your machine can run, or when the run is part of an automated pipeline. Docker's own cloud sandboxes are one option. Lizard Sandboxes are another.

Lizard Sandboxes are Firecracker microVMs, each with its own kernel. With Lizard CLI, connect a credential once, create a Codex sandbox and send it a prompt:

lizard agents login chatgpt --project <project>
lizard agents status --project <project>
lizard sandbox create -t codex -s small --timeout 1800000 --project <project>
lizard sandbox exec <id> -- git clone <repo-url> /workspace/app
lizard sandbox prompt <id> --cwd /workspace/app "Inspect the repository and report its test command"

Replace <project> with the same project name throughout, <id> with the printed sandbox ID and <repo-url> with your repository. create does not upload your local checkout, so the agent sees only what you clone or copy into the sandbox. lizard agents login chatgpt --project <project> signs in with a device code. To use an OpenAI API key instead, run lizard agents add openai, then lizard agents use codex --credential openai. Credentials belong to the project: connect them once and every sandbox in that project uses them. lizard agents docs.

Lizard CLI gives a sandbox a five-minute lifetime unless you set one. The example asks for 1,800,000 ms, which is 30 minutes. Commands do not reset the deadline. On the trial, every sandbox is deleted one hour after it starts at the latest, and a longer timeout is refused. After the first payment, lizard sandbox timeout <id> <ms> extends a lifetime, up to 596 hours. Push commits or copy results out of the sandbox before its deadline. Limits.

The Lizard pricing page lists Pro at $19 a month, including $19 of usage. Usage above that is pay as you go. Small (2 vCPU, 4 GB) costs $0.0162 an hour, Medium (4 vCPU, 8 GB) $0.0324 and Large (8 vCPU, 16 GB) $0.0648. Sandboxes are billed per second while they run, idle time included, and a paused sandbox has no compute charge. Egress is included up to 2 TB per account over a rolling 30 days, and Persistent Volumes are billed separately. Prices checked November 11, 2026.

Published USD hourly compute rates for equal CPU and memory:

These are list rates only. Disk sizes, plan fees, included usage and limits differ, so price your own workload before you choose.

During the 7-day trial you can run 1 Small and 2 Mini sandboxes at a time, in US regions only, with 50 Small and 100 Mini starts in all. Medium and Large come with the first payment. After that, the Lizard limits table allows Pro up to 40 running vCPU, which is 20 Small sandboxes, with unlimited starts. The limit counts across all of the account owner's workspaces. When you compare with a local Docker Sandbox, count the Pro fee, the hours your agents run and your model costs. The AI sandbox overview covers the wider choice between local and cloud isolation.

FAQ

Is a Docker Sandbox a container? No. Each Docker Sandbox is a microVM with its own kernel and a private Docker Engine. Containers that the agent starts run inside that VM.

Does Docker Sandboxes require Docker Desktop? No. The standalone sbx CLI needs neither Docker Desktop nor Docker Engine. Local sandboxes still need a supported OS and hardware virtualization.

Can a Docker Sandbox change my local files? Yes, with a direct mount, which is the default for sbx run. Clone mode gives the agent its own Git clone, and a mountless sandbox gets no host files.

What survives stopping a local Docker Sandbox? Installed packages, Docker images and files inside the VM survive a stop. sbx rm deletes them. Directly mounted files stay on your host either way.

Can Docker Sandboxes run Codex and OpenCode? Yes. Run sbx run codex . or sbx run opencode . after you store the provider credentials with sbx secret set.

Is Docker Sandboxes free? Local sandboxes and the sbx CLI are free, including for commercial work. Cloud sandboxes are metered per second, from $0.07 an hour for Micro (1 vCPU, 2 GB) and $0.14 an hour for Small (2 vCPU, 4 GB). Your model provider bills model usage separately.

Will my agent keep working when I close my laptop? Not in a local sandbox. A cloud sandbox, from Docker or Lizard, keeps running until its lifetime ends. Lizard trial sandboxes are deleted within one hour of starting.