Open main menu

Claude Code Sandbox: Every Option Compared, from /sandbox to Always-On VMs (2026)

Two different things are called a Claude Code sandbox: the built-in /sandbox feature and real isolation around the whole agent. Every tier compared, with honest October 2026 prices and what each one actually protects.

VishnuVishnu

•

Published on

•

Claude Code Sandbox: Every Option Compared, from /sandbox to Always-On VMs (2026)

Table of Contents

Do not index
A Claude Code sandbox is an isolation boundary that limits what Claude Code can touch while it works: which files it can write, which network hosts it can reach, and how badly a bad command can hurt you. Two very different things ship under that name. The built-in /sandbox feature wraps only shell commands and is off by default, while a real container, VM, or hosted sandbox wraps the whole agent, which is what Anthropic itself says you need before running --dangerously-skip-permissions. This guide compares every tier with October 2026 prices, from free local tools to always-on sandboxes like Agent37 from $4.76 per month.
The short version: enable the built-in sandbox for day-to-day prompting comfort, use a container or VM the moment you go unattended, and use a persistent hosted sandbox when the agent needs to outlive your laptop.

What a Claude Code sandbox actually means

Search for "claude code sandbox" and you will find two separate ideas wearing one name.
The built-in sandboxed Bash tool. Since v2.0.24 (October 2025), Claude Code can run shell commands inside an OS-enforced boundary: Seatbelt on macOS, bubblewrap plus socat on Linux and WSL2. You toggle it with the /sandbox command or "sandbox": {"enabled": true} in settings. It limits where commands write and which domains they reach, and because the operating system enforces the limits, Claude Code can run sandboxed commands without asking you to approve each one. Anthropic measured an 84 percent drop in permission prompts in internal usage.
A sandbox around all of Claude Code. A Docker container, a devcontainer, a local or cloud VM, or a hosted sandbox service that contains the entire process: shell commands, file edits, MCP servers, hooks, everything. This is the tier Anthropic's docs mean when they say, verbatim: "Always run --dangerously-skip-permissions sessions inside a container, a VM, or the sandbox runtime, so that file tools, MCP servers, and hooks are also inside the boundary."
The first is a comfort and safety feature. The second is a hard requirement for autonomous work. Most of the confusion online comes from treating them as interchangeable.

Why sandbox Claude Code at all

Because the failure cases are real, documented, and recent.
In July 2025, Replit's coding agent deleted a production database holding records on over 1,200 executives during a widely reported "vibe coding" experiment, despite explicit instructions not to change anything. The same month, an attacker slipped a prompt into Amazon Q's VS Code extension instructing it to wipe users' home directories; the payload shipped in a signed release of an extension with roughly a million installs, and thousands of users downloaded the tainted version in the two days before AWS pulled it (the malformed prompt reportedly never executed).
Claude Code itself has patched real sandbox vulnerabilities. CVE-2026-39861, fixed in v2.1.64, let a prompt-injected command create a symlink inside the workspace that the unsandboxed side of Claude Code would follow, writing to files outside the boundary, such as ~/.bashrc. And in November 2025, Anthropic disclosed that a state-sponsored group had manipulated Claude Code into attempting infiltration of roughly thirty organizations, with the AI performing 80 to 90 percent of the campaign autonomously.
None of this means the sky is falling. It means the vendor's own warning deserves a literal reading: bypassPermissions "offers no protection against prompt injection or unintended actions." Isolation is the control that still works when the model is wrong or deceived. If you want the architecture background on how strong each isolation tier is, we compared gVisor, microVMs, and full VMs in depth.

The built-in /sandbox: what it protects, and what it does not

The built-in sandbox is genuinely good, and genuinely narrow. As of Claude Code 2.1.296 (October 2026), here is the honest picture.
What you get when you turn it on:
  • Writes are limited to your working directory and a per-user temp directory. Claude Code's own config surfaces (settings files, .git/hooks, .mcp.json, shell startup files) are always write-denied, with no way to exempt them.
  • Network starts at zero. Commands reach the internet only through a local proxy that checks every host against your allowlist.
  • Sandboxed commands run without permission prompts, which is the whole point: flow instead of click fatigue.
What it does not cover, straight from the docs:
  • It only wraps shell commands. "The sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it."
  • It is off by default. You must run /sandbox or set sandbox.enabled yourself.
  • Reads are open by default. Commands can read "most of the machine, including credential files such as ~/.ssh", and "there is no built-in credential deny list." You have to configure denyRead or the sandbox.credentials block yourself.
  • There is an escape hatch. When a command fails inside the sandbox, Claude may retry it with a parameter literally named dangerouslyDisableSandbox. Who approves that retry depends on your permission mode. Strict sandbox mode ("allowUnsandboxedCommands": false) removes the hatch entirely, and since v2.1.285 an admin-enforced strict sandbox cannot be loosened by repository settings.
  • Missing dependencies fail open. If bubblewrap or socat is absent, Claude Code runs commands unsandboxed unless you set failIfUnavailable: true.
  • Native Windows is not supported. On Windows, commands run unsandboxed unless you work inside WSL2.
Anthropic's own summary is the right one: the sandboxed Bash tool "on its own constrains only shell commands, so it is not sufficient for fully unattended runs."

sandbox-runtime: the whole process, no Docker

Between the built-in tool and a container sits @anthropic-ai/sandbox-runtime (srt), the Apache-2.0 project Anthropic open-sourced in October 2025 and builds the embedded sandbox on. Around 5,500 GitHub stars as of October 2026, labeled a beta research preview.
Run npx @anthropic-ai/sandbox-runtime claude and the same Seatbelt or bubblewrap isolation wraps the entire Claude Code process, including file tools, MCP servers, and hooks. Defaults are stricter than the embedded version: writes denied everywhere until allowed, all network denied until allowed. You grant your project directory, ~/.claude, temp, and api.anthropic.com, and you have a credible lightweight boundary for unattended runs on a trusted machine, with no image builds and no daemon.
The honest caveats: it shares your host kernel, so a kernel exploit is still an escape route, and the proxy does not terminate TLS by default, so domain fronting can slip the network allowlist. For untrusted code, step up a tier.

Docker and devcontainers: the standard answer for YOLO mode

The community phrase "YOLO mode" means --dangerously-skip-permissions, and the standard way to run it safely is a container you can afford to lose.
Anthropic maintains a reference devcontainer in the Claude Code repo with three parts: a devcontainer.json, a Dockerfile, and init-firewall.sh, a default-deny iptables egress firewall. The docs are explicit that this combination "supports running Claude Code with --dangerously-skip-permissions for unattended work." There is also an official Dev Container Feature (ghcr.io/anthropics/devcontainer-features/claude-code) for adding Claude Code to any existing devcontainer. Community projects fill the gaps for plain Docker: claudebox (about 1,200 stars) and coi (about 750) are the active ones people actually use.
Three operational details matter more than the Dockerfile:
  1. Run as a non-root user. Claude Code refuses to start with --dangerously-skip-permissions as root on Linux and macOS.
  1. Auth without a browser. Pass ANTHROPIC_API_KEY as an env var for API billing, or mint a one-year subscription token on your own machine with claude setup-token and pass it as CLAUDE_CODE_OAUTH_TOKEN (works on Pro, Max, Team, and Enterprise plans, model requests only). To make interactive logins survive rebuilds, mount a volume at ~/.claude and point CLAUDE_CONFIG_DIR at it; the account record lives in ~/.claude.json, which otherwise sits outside the volume.
  1. Do not mount host secrets. Anthropic's warning is blunt: with permissions skipped, "dev containers do not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in ~/.claude." Keep ~/.ssh and cloud credentials out, and use repo-scoped, short-lived tokens.
A container bounds the blast radius to things inside the container. What the agent can read, it can still leak through any network egress you allow. That stays true in every tier below, too.

Hosted sandboxes that run Claude Code, with real prices

Every major sandbox provider published a Claude Code guide in the last year. What almost none of them publish is comparable numbers, so here are the ones we could verify in October 2026.
Anthropic's own hosted option is Claude Code on the web: cloud sessions on Pro, Max, and Team plans (plus Enterprise premium seats), each running in "an isolated, Anthropic-managed virtual machine" with proxy-enforced network limits and your git credentials held outside the sandbox. There is no separate charge for the VM; sessions burn your plan's usage limits. It is the easiest real isolation you can get, and we covered it fully in our Claude Code cloud guide. The limits: sessions are ephemeral, idle VMs get reclaimed, and running background work dies with them.
For third-party sandboxes, Fly.io published its own comparison on October 5, 2026 for a 2 vCPU / 4 GB workload at 30 percent average CPU. By Fly's arithmetic, per hour: Sprites $0.06, Cloudflare $0.12, Vercel $0.16, E2B $0.17, Daytona $0.17, Modal $0.24. Treat it as a competitor's math, but the per-second list rates behind it check out: E2B and Daytona both meter at $0.000014 per vCPU-second plus RAM, which lands near $0.17 per hour for this shape.
Provider
Official Claude Code guide
Pricing basis (Oct 2026)
Session limits
E2B
Yes, prebuilt claude template
~$0.17/hr at 2 vCPU/4 GB, per-second metering
1 hr continuous on the free tier, 24 hr on Pro ($150/mo)
Daytona
Yes, CLI and SDK guides
~$0.17/hr, per-second metering
No duration cap
Modal
Yes, official sandbox example
~$0.24/hr for the same shape
24 hr max per sandbox (default 5 min; snapshot to go longer)
Fly.io Sprites
Yes, Claude Code preinstalled
$0.0385/CPU-hr + $0.021875/GB-hr of use
No cap, auto-suspends when idle
Cloudflare Sandboxes
Yes, official docs tutorial
Active-CPU metering on Workers Paid ($5/mo base)
No duration cap
Vercel Sandbox
Yes, via the Claude Agent SDK
$0.128/hr active CPU + provisioned memory
45 min on Hobby, longer on paid plans
Agent37
Yes, agent37-claude-code template
$4.76/mo for 2 vCPU/4 GB/4 GB disk, 730 hours
Persistent, no cap
One billing gotcha applies everywhere: sandbox compute is separate from model usage. Inside any of these, Claude Code still bills your Anthropic API key or subscription token. No sandbox vendor, including Agent37, can supply Claude usage for you.

Which Claude Code sandbox should you use?

This is the decision table nobody on the first page of Google actually publishes.
Option
Isolation strength
Covers file tools/MCP?
Platforms
Cost
Best for
Built-in /sandbox
OS-level, Bash commands only
No
macOS, Linux, WSL2
Free
Interactive daily coding with fewer prompts
sandbox-runtime (srt)
OS-level, whole process
Yes
macOS, Linux (Windows alpha)
Free
Unattended runs on trusted repos, no Docker
Devcontainer / Docker
Container + egress firewall
Yes
Anywhere Docker runs
Free (your hardware)
YOLO mode on repos you mostly trust
Local VM / microVM
Hardware virtualization
Yes
Needs virtualization support
Free to cheap
Untrusted code on your own machine
Claude cloud sessions
Anthropic-managed VM
Yes
Browser, mobile, CLI
Included in Pro/Max/Team limits
Delegating tasks without infrastructure
Ephemeral cloud sandbox (E2B, Daytona, Modal...)
microVM or gVisor
Yes
Any
~$0.06 to $0.24/hr
CI jobs, bursts, programmatic fleets
Persistent cloud sandbox (Agent37)
gVisor, or full KVM VM
Yes
Any
$4.76/mo always-on
Agents that keep state and run 24/7
The pattern behind the table: match the boundary to how much you trust the code and how long the agent runs. Prompting interactively on your own repo, the built-in sandbox is enough. Letting Claude run unattended for an hour, use srt or Docker. Working on code you did not write, use a VM-class boundary. And once the agent needs to run longer than your terminal session, the question stops being "which sandbox" and becomes "whose computer."

Running a Claude Code sandbox 24/7

Here is the gap in every tutorial above: they all end with a one-shot claude -p demo, then the sandbox dies with your terminal. Real agent workflows are not one-shot. A code-review bot, an overnight refactoring queue, a cron job that triages issues at 6 a.m.: these need a sandbox that is still there when your laptop is not.
You can rent a VPS and maintain the container yourself; we priced that option in our VPS for AI agents guide, and a 4 GB box typically lands at $20 to $24 per month before you spend a weekend on firewalls and updates. Ephemeral sandbox pricing is worse for this: at Daytona's metered rates, a 730-hour month of 2 vCPU / 4 GB runs to roughly $120, and on E2B the same month needs the $150 per month Pro plan on top of roughly $120 in usage.
This is the case Agent37 was built for. One API call creates a persistent sandboxed computer from the agent37-claude-code template:
  • Isolation by default. Every standard instance runs under gVisor ("Isolation enforced by the kernel", with a hard per-instance disk quota), the same runtime Modal uses for sandboxing. If you need a stronger boundary, a vm instance is "a full Linux virtual machine with its own kernel and KVM hardware virtualization" at 2.5x the compute rate, from $11.36 per month.
  • Honest cost. The standard 2 vCPU / 4 GB / 4 GB disk shape is $4.76 per 730-hour month, metered by the minute with no plan fee. Turn on auto-sleep and a mostly idle agent costs a fraction of that: awake an hour a day works out to about $0.54 per month, because sleeping instances pay for disk alone. Agent37's own pricing page compares 31 providers at published rates and backs the "95% lower cost than most sandbox providers" headline with a refund-the-difference guarantee.
  • Your Anthropic account, three ways. Open the instance terminal and run claude auth login, or pass a CLAUDE_CODE_OAUTH_TOKEN minted with claude setup-token, or set ANTHROPIC_API_KEY on the create call. Agent37 never supplies or bills Claude model usage; the honest math is sandbox from $4.76 plus whatever you already pay Anthropic. There is also a bring-your-own-model path via ANTHROPIC_BASE_URL for compatible endpoints.
  • State survives. Files, sessions, and logins persist until you delete the instance. That is the practical difference between a sandbox priced for ephemeral bursts and one priced to be your agent's permanent computer.
New workspaces get a $5 starter credit once a card is on file (adding the card charges nothing), which covers just over a month of the entry sandbox. And if you want a Claude Code box without touching an API at all, Agent37's personal plans deploy one in a click, including a free tier that sleeps when idle.

FAQ

Is Claude Code sandboxed by default?

No. The built-in Bash sandbox is off by default; you enable it with /sandbox or sandbox.enabled in settings. What Claude Code has by default is the permission system; since v2.1.283 sessions start in auto mode, where a classifier model reviews actions and you are prompted only for what it escalates. On native Windows, commands run unsandboxed entirely; use WSL2.

Is it safe to run claude --dangerously-skip-permissions?

Only inside real isolation. Anthropic's docs say to always run it inside a container, a VM, or the sandbox runtime, because the flag removes every prompt that would otherwise catch a mistake. Even sandboxed, avoid it on repositories you do not trust: isolation bounds the damage to what is inside the boundary, and anything readable can still leak through allowed network egress.

Does the built-in sandbox stop prompt injection?

No. It shrinks what a hijacked command can do, which is valuable, but file tools, MCP servers, and hooks run outside it, commands can read most of your machine by default, and Claude can request an unsandboxed retry. Treat it as a guardrail, not a security boundary for adversarial inputs.

Can Claude disable its own sandbox?

By design there is a retry path with a dangerouslyDisableSandbox parameter, gated by your permission mode. Lock it down with strict sandbox mode ("allowUnsandboxedCommands": false), which makes unsandboxed retries impossible, and since v2.1.285 an enforced strict sandbox cannot be loosened by project settings.

What does a Claude Code sandbox cost?

Local options are free. Ephemeral cloud sandboxes run roughly $0.06 to $0.24 per hour for a 2 vCPU / 4 GB shape, which is about $44 to $175 if left up all month. A persistent Agent37 sandbox is $4.76 per month always-on, or about $0.54 per month awake an hour a day with auto-sleep. Model usage always bills separately to your Anthropic account, whatever sandbox you pick.
Sandbox first, autonomy second. Turn on /sandbox today for the prompt relief, keep YOLO mode inside a boundary you can afford to lose, and when your agent earns a permanent job, give it a permanent, isolated computer. Spin one up on Agent37 Cloud with the $5 starter credit and the first month of the sandbox is effectively free.
Vishnu

Written by

Vishnu

Founder at Agent37, which runs managed hosting for OpenClaw and Hermes agents for 1,000+ users. Writes about what actually breaks when you leave an AI agent running.

    Related posts