Sandboxing
Rules are patterns over command text. The sandbox is the operating system saying no, which is a stronger kind of no.
With the Bash sandbox on, commands run inside a boundary the operating system enforces: you say which files and which domains are reachable, and every command and every child process is held to it. Because the boundary is real, Claude can run most commands without stopping to ask.
/sandboxA panel opens showing whether the sandbox is on and what it allows.
On macOS it is built in and uses Seatbelt, with nothing to install. On Linux and WSL2 it needs two packages, and the panel tells you if they are missing. Native Windows is not supported: run Claude Code inside WSL2 there.
Why it changes the trade
Without a sandbox, letting it run commands unattended means trusting a list of patterns. With one, a command that tries to touch a file outside the boundary fails, whatever it was called and however it was spelled.
- Fewer prompts, not fewer limits. The point is to be interrupted less while being protected more.
- Network too. The allowed domains are part of the boundary, so a command cannot quietly reach somewhere else.
- It combines with modes. Plan mode still refuses to edit your source, sandbox or not.
- Run
/sandboxand read what your machine reports. - Turn it on and ask for something that touches a file outside the project.
You understood something today that you didn't yesterday.