Permission rules decide whether a command runs. They judge the command string before it starts, which is why a rule can be sidestepped by spelling the same thing differently. The sandbox answers a different question: once a command is running, what can it touch? The operating system enforces the answer for the command and every child process it starts, whatever the command turns out to do.
That’s what lets you stop approving every npm test by hand. You define the boundary once; anything that stays inside it can run without asking.
Turning it on
Run /sandbox and pick a mode. Auto-allow runs sandboxed commands without a prompt; regular permissions keeps the prompts but still sandboxes. The choice is saved to .claude/settings.local.json; set sandbox.enabled to true in ~/.claude/settings.json to use it everywhere. It runs on macOS (using the built-in Seatbelt framework) and on Linux and WSL2 (using bubblewrap and socat). Native Windows isn’t supported.
What the boundary is
- Writes: by default only the working directory, a per-user temp directory and any directories you’ve added. Even inside those, config files like
.claudesettings,.mcp.jsonand shell startup files are protected, so a command can’t grant itself new powers. - Reads: most of the machine stays readable, credential files included, unless you block them with
denyReadorsandbox.credentials. - Network: traffic goes through a proxy outside the sandbox. No domains are pre-allowed; the first time a command needs a new one, you’re asked.
sandbox.network.allowedDomainspre-approves the ones you trust.
When a command fails inside the sandbox, Claude may retry it outside, but that retry goes back through the normal permission flow. Set allowUnsandboxedCommands to false to close that door.
The catch
This sandbox covers shell commands only: Bash, PowerShell and Monitor. Read and Edit go through permission rules instead, and MCP servers and hooks run unconstrained on your machine. To put everything behind one wall, run the whole of Claude Code inside the sandbox runtime (npx @anthropic-ai/sandbox-runtime claude), a dev container or a VM. The docs say --dangerously-skip-permissions should only ever run inside one of those.
It’s also not airtight. The proxy checks hostnames without inspecting encrypted traffic, so allowing a broad domain like github.com leaves room for data to leak out. Allow only what you need.