The Claude Code sandbox is an operating system boundary around shell commands, not around everything Claude does. It is off by default and turned on with the /sandbox command. File tools, MCP servers and hooks run outside it, which is the gap most people miss.
What it restricts
Anthropic's documentation says commands run inside the boundary, along with the processes they start. Defaults:
- Writes: the working directory, a per-user temp directory and directories you added. Protected paths stay denied.
- Reads: most of the machine, including credential files such as ssh keys and cloud credentials, unless you deny them.
- Network: no direct route out. Traffic goes through a proxy on your machine that checks each host against allowed domains, which start empty.
- Environment variables: inherited from Claude Code, including any secrets in its environment.
Note the read default. A sandboxed command can still read credential files unless you change that.
Platforms and setup
The sandbox runs on macOS, Linux and WSL2. On native Windows, commands run unsandboxed. macOS uses the built-in Seatbelt framework. Linux and WSL2 need bubblewrap and socat. It is built on the open source sandbox-runtime package.
Run /sandbox, pick a mode (auto-allow or regular permissions), and ask Claude to run a command. You can also set sandbox enabled to true in a settings file. By default, if the sandbox cannot start, Claude Code runs commands without sandboxing unless you set the fail-if-unavailable option.
What runs outside
The documentation lists:
- Built-in file and web tools such as Read, Edit, Write, WebFetch and WebSearch, which follow permission rules instead.
- Command hooks, local MCP servers, plugin monitors, LSP servers and helper commands, which run with your full access.
- Commands you type yourself at the shell prompt in most sessions, excluded commands, and unsandboxed retries Claude can ask for.
For one boundary around all of it, the docs suggest running the whole Claude Code process in a container, virtual machine or the sandbox runtime.
How to confirm it works
Ask Claude to run a write to your home directory. It should fail. A request to a host outside the proxy should fail to resolve. If Claude asks to retry unsandboxed, decline unless you have a reason.
Takeaway
A sandbox narrows what a bad command can do. It does not make hooks or local MCP servers safe, so review those separately. Our Claude Code security practical guide goes further.
Safeguard offers a free scan at gold.safeguard.sh/scan.
Tightening the defaults
The settings table in the documentation names the controls: filesystem allow and deny lists for writes, a deny list for reads, and allowed and denied network domains. A sensible first step is to deny reads of credential directories and to keep the allowed domain list short, adding a host only when a command genuinely needs it. For managed deployments, the docs also describe enforcing the sandbox with managed settings, so developers cannot quietly turn it off.
Quick check
Is the sandbox on by default?
No. The documentation says it is off by default, and you turn it on with /sandbox.
Does it cover MCP servers?
No. Local MCP servers run outside the sandbox with your full access.
Sources
Last reviewed: 19 October 2026.