Claude Code Sandbox Mode, Docker or a Cloud VM: Which to Use?
Updated October 27, 2026 .md
Short answer: Use Claude Code's built-in sandbox to cut prompts in everyday work on your own machine. Use a dev container when the team wants one standard, firewalled setup. Use a cloud VM for unattended runs, untrusted repos, work that needs Docker or KVM, or tasks that must keep running while your laptop sleeps.
These three options aren't rivals. They sit at different layers, and you can stack them. This page compares what each one actually stops, based on Anthropic's own docs and on tests we ran on a Sandboxer VM.
The decision table#
Claude Code sandbox (/sandbox) |
Local Docker / dev container | Cloud VM (Sandboxer) | |
|---|---|---|---|
| What it wraps | Shell commands Claude runs and their child processes | The whole Claude Code process and your toolchain | The whole Claude Code process, on its own kernel |
| Still outside the boundary | Claude's file tools, MCP servers and hooks run on your host | Anything you mount in: the workspace bind mount is your real repo | Only what you put in the VM |
| Reads | Most of your machine, including ~/.ssh and ~/.aws/credentials, unless you deny them |
Only what's in the container or mounted | Only what's in the VM; with --no-env, none of your secrets |
| Writes | Working directory, added dirs and $TMPDIR |
The container, plus the mounted repo on your host | The VM's own disk |
| Network | Off by default; allowed domains go through a proxy on your machine | Open, unless you add a firewall like Anthropic's reference init-firewall.sh |
Open outbound by default |
| Runs on | macOS, Linux, WSL2 (not native Windows) | Any host running Docker | Any laptop with the sbx CLI or a browser |
| Docker inside | docker is incompatible; you exclude it from the sandbox |
Needs the host's Docker socket or a privileged container | Preinstalled, with its own daemon |
/dev/kvm |
Not applicable | Only if you pass the host's device in | Available to the user account |
| When your laptop sleeps | Stops | Stops | Keeps running |
| Parallel tasks | Limited by your machine | Limited by your machine | One VM per task, up to your plan's limit (2 on the trial, 100 on the $20 plan) |
| Cost | Free | Free (your hardware) | default size $0.036/hour, per second; stopped costs nothing |
Model usage is billed by Anthropic in every column. None of these options changes what Claude sends to the model.
Option 1: Claude Code's built-in sandbox#
Anthropic's sandboxing docs describe a per-command boundary built on operating-system primitives: Seatbelt on macOS and bubblewrap on Linux and WSL2. It's off by default; turn it on with /sandbox or sandbox.enabled: true in your settings.
What it gives you, in Anthropic's words:
- Writes are limited to "the current working directory and its subdirectories", added directories, and the temp directory in
$TMPDIR. - Reads are not: the default is "read access to the entire computer, except certain denied directories. This default still allows reading credential files." There is "no built-in credential deny list", so you list what to protect under
sandbox.credentials. - A sandboxed command "has no direct route to the network". Traffic goes through a proxy Claude Code runs on your machine, and "your allowed domains start empty."
- "The sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it."
- "On native Windows, Claude Code runs commands unsandboxed." Use WSL2 there.
Two practical catches. When a command fails in the sandbox, Claude can retry it with dangerouslyDisableSandbox, and that retry runs unsandboxed unless you set allowUnsandboxedCommands: false. And docker is incompatible with it, so Docker commands have to be excluded from the sandbox entirely.
Anthropic's sandbox environments page is explicit that this mode alone "is not sufficient for fully unattended runs". It's built to reduce prompts while you're at the keyboard.
Option 2: A local Docker container#
Anthropic publishes a dev container guide and a reference container with a default-deny egress firewall. Inside it, the whole Claude Code process is contained, including file tools and MCP servers, and it runs as a non-root user, so --dangerously-skip-permissions works.
The limits are in the same doc. The workspace is bind-mounted, so "Claude can still modify any file in the bind-mounted workspace, which appears directly on your host." With prompts skipped, the container does "not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in ~/.claude." Anthropic advises against mounting ~/.ssh or cloud credential files.
A container also shares your host's kernel. If the agent needs to build images, run docker compose or start a VM, you either mount the host's Docker socket (which hands the agent control of your host's Docker) or run privileged. And it stops when you close the lid.
Option 3: A cloud VM#
Anthropic's docs say a dedicated VM "provides the strongest separation, with its own kernel", and recommend one for untrusted repositories. A Sandboxer sandbox is a Cloud Hypervisor microVM with Claude Code preinstalled. These are the checks we ran on a fresh one. We don't have an Anthropic key on the test account, so no model ran: everything below tests the VM, not Claude's output.
Claude Code is already there#
sbx new --name aeo-ccmodes-1 --no-env
sbx exec sb_zuu52yrorm "claude --version"2.1.301 (Claude Code)A --no-env VM holds none of your credentials#
--no-env gives the VM none of your stored variables, secret files, repository credentials or agent logins.
sbx exec sb_zuu52yrorm "env | cut -d= -f1 | grep -iE 'key|token|secret|anthropic|openai|github|aws'"
sbx exec sb_zuu52yrorm "ls -A ~/.ssh ~/.aws ~/.config/gh ~/.claude"
sbx exec sb_zuu52yrorm "gh auth status"
sbx exec sb_zuu52yrorm "claude -p 'say hi'"SANDBOXER_TOKEN
ls: cannot access '/home/user/.aws': No such file or directory
ls: cannot access '/home/user/.config/gh': No such file or directory
ls: cannot access '/home/user/.claude': No such file or directory
/home/user/.ssh:
You are not logged into any GitHub hosts. To log in, run: gh auth login
Not logged in · Please run /loginNo Anthropic, GitHub or cloud keys, an empty ~/.ssh, and no Claude login. Pass only what a task needs with -e ANTHROPIC_API_KEY=…. The one variable left, SANDBOXER_TOKEN, is there by design: in a --no-env sandbox it is limited to sandbox.read and host on that one sandbox. We checked: with it, listing sandboxes returned just this one, and creating a new sandbox returned 403.
Docker and KVM work inside#
sbx exec sb_zuu52yrorm "id -nG"
sbx exec sb_zuu52yrorm "ls -l /dev/kvm"
sbx exec sb_zuu52yrorm "docker run --rm hello-world | grep Hello"user sudo docker kvm
crw-rw---- 1 root kvm 10, 232 Oct 27 02:46 /dev/kvm
Hello from Docker!The agent gets its own Docker daemon, with no socket shared from your machine, and it can open /dev/kvm as the normal user account. See Docker and nested KVM inside an agent sandbox for Compose, kind and QEMU.
You can still stack Claude's sandbox on top#
In an unprivileged container, Anthropic's docs say bubblewrap "can't mount a fresh /proc", so you need enableWeakerNestedSandbox. In the VM, after sudo apt-get update && sudo apt-get install -y bubblewrap (it isn't preinstalled), a fresh /proc and an empty network namespace both work. Inside, there's no uplink and ps sees only the few processes inside the sandbox (5 lines, header included):
sbx exec sb_zuu52yrorm "bwrap --ro-bind / / --dev /dev --proc /proc --unshare-net --unshare-pid sh -c 'ip -brief link; ps -e | wc -l'"lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
tunl0@NONE DOWN 0.0.0.0 <NOARP>
sit0@NONE DOWN 0.0.0.0 <NOARP>
5So you can run Claude Code with /sandbox on inside the VM, for per-command network limits on top of the VM boundary.
What the VM doesn't do#
Outbound internet is open by default, so the VM can leak anything you give it, such as an API key or your code. Use a dedicated key with a spend limit, or turn on Claude's sandbox inside the VM to limit domains. When you're done, sbx delete <id> --yes.
Which one, by situation#
| You want to | Use |
|---|---|
| Fewer prompts while you work on your own laptop | Claude Code's /sandbox |
| One reviewed setup the whole team runs locally | Anthropic's dev container, with its firewall |
Run --dangerously-skip-permissions unattended |
A cloud VM with --no-env (see the safe setup) |
| Open a repo you don't trust | A cloud VM you delete afterwards |
| Let the agent build images, run Compose or an emulator | A cloud VM |
| Keep a task running overnight with the laptop closed | A cloud VM (see Run Claude Code in a cloud VM) |
| Run several tasks at once | One cloud VM per task (see parallel agents) |
| Work on native Windows | WSL2 with /sandbox, a container, or a cloud VM |
FAQ#
Does Claude Code's sandbox mode stop it reading my SSH keys?#
Not by default. Anthropic's docs say reads cover "the entire computer, except certain denied directories" and that this "still allows reading credential files". Add the paths and variables you want hidden under sandbox.credentials.
Is Claude Code's sandbox enough for --dangerously-skip-permissions?#
Anthropic says no: it constrains only shell commands, and file tools, MCP servers and hooks run outside it. Anthropic recommends a container, a VM or its sandbox runtime for bypass-mode sessions.
Does Claude Code sandboxing work on Windows?#
Not natively. On native Windows, commands run unsandboxed. Run Claude Code inside WSL2, where it uses bubblewrap as on Linux, or use a container or VM.
Why not just run the dev container on a cloud server?#
You can, and Anthropic's docs mention GitHub Codespaces. You still have a container on a shared kernel, and Docker-in-Docker or KVM still need extra privileges. A microVM gives the agent its own kernel, Docker daemon and /dev/kvm without them.
Can I use more than one of these?#
Yes. Anthropic's docs describe running the built-in sandbox inside a container or VM for command-level limits on top of the outer boundary. In a Sandboxer VM, bubblewrap works without the weaker nested mode.
Related#
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.