The sandbox: a boundary the system enforces

In the last lesson you learned to allow and deny actions with rules. But rules have a blind spot. The rule Bash(npm test) lets the tests run — and has no idea what is inside them. If a test or one of its dependencies starts writing into someone else’s folder or sending data over the network, the rule will not notice.

That is what the second layer is for — the sandbox.

What the sandbox does

The sandbox wraps the shell commands Claude runs in a boundary enforced by the operating system. By default, a command inside it:

• writes only to the project folder, the user’s temp folder, and folders you added with --add-dir or /add-dir;
• reaches the network only through a proxy that lets through allowed hosts and nothing else.

If a command tries to write a file into your home folder, the system refuses: on macOS you see Operation not permitted, on Linux Read-only file system.

How to turn it on

The sandbox is off by default. Inside a session, type:

/sandbox

and on the Mode tab choose the auto-allow mode. In it, a command that runs inside the sandbox does not need approval: the boundary already keeps it in check. Claude Code saves the choice to your personal .claude/settings.local.json.

In the settings file it looks like this:

{
  "sandbox": {
    "enabled": true
  }
}

What stays outside

This matters if you do not want to overestimate the protection:

• Claude’s own tools for reading and editing files and for the web run outside the sandbox — the permission rules from the last lesson govern them;
• hooks and local MCP servers run outside the sandbox with your full user rights.

The sandbox does not replace rules; it adds to them. Rules decide what may be run. The sandbox decides what the running thing may do.