What a sandbox does
Permission rules and hooks decide whether a command may start. A sandbox limits what a command can do once it's running: which folders it can write to, which files it can read and which hosts it can connect to. That closes the gap rules leave, because it applies to every child process, including a script the agent wrote a second ago.
Option 1: the built-in sandbox
Type /sandbox in Claude Code to turn it on. Shell commands then run inside an operating-system sandbox: Seatbelt on macOS, bubblewrap on Linux.
- Writes are limited to the project folder, plus any paths you add.
- Network access goes through a proxy that only allows the domains you approve.
- Commands that stay inside the limits can be approved automatically, which removes most prompts without removing the protection.
- Reads are open by default. Add deny rules for the folders you want closed, such as
~/.sshand~/.aws.
Some tools don't work inside it, typically ones that need Docker, system services or unusual paths. You can exclude specific commands, and each exclusion is a hole, so keep the list short.
Option 2: a dev container or Docker
Running Claude Code inside a container puts the whole agent, not only its shell commands, in a separate filesystem. Anthropic's reference dev container adds a firewall that only allows the hosts development needs. This is the usual setup for --dangerously-skip-permissions.
- Strong isolation from your home folder, keychain and other projects.
- Slower file access on a Mac, and more setup: your toolchain has to exist inside the container.
- The project folder is still mounted, so the agent can still delete or damage it.
- Whatever credentials you pass in are available to the agent.
Option 3: a virtual machine or a remote environment
A VM, a cloud workspace or the web version of an agent gives the cleanest separation. Nothing on your Mac is reachable. The cost is distance from your local setup.
How Codex CLI compares
Codex sandboxes by default. Its workspace-write mode limits writes to the project and turns network access off unless you enable it, read-only allows no changes, and danger-full-access removes the sandbox. It also uses Seatbelt on macOS.
Which to use
| Situation | Reasonable choice |
|---|---|
| Everyday supervised work | Default prompts, plus deny rules and a hook |
| Long tasks on your Mac with fewer prompts | The built-in sandbox with a short list of allowed domains |
| Fully unattended runs | A dev container or VM with no real credentials |
| Untrusted code or repositories | A VM or remote environment |
What a sandbox doesn't protect
- The project itself. Writes are allowed there by design, so the agent can still delete your source, your uncommitted work and your
.gitfolder. - Secrets inside the project. A
.envin the project folder is readable unless you add a rule for it. - Tools outside the shell. The sandbox covers shell commands. Claude's own file tools and MCP servers follow permission rules instead.
- Allowed hosts. If a domain on your list accepts uploads, data can leave through it.
Covering the inside with Rollcage
Rollcage works on the part a sandbox leaves open. Snapshots clone the project when the agent starts, so damage inside the allowed folder can be undone. The Guard blocks reads of secret files in the project and commands that print the environment. The secrets leak scan finds keys that reached a transcript anyway. It isn't a sandbox itself, and the two are best used together.
Questions
Does Claude Code have a sandbox on macOS?
Yes. The /sandbox command turns on sandboxing for shell commands using Seatbelt, the sandbox built into macOS. No Docker is needed.
Is the sandbox on by default?
No. You turn it on per project or in your settings. Codex CLI, by contrast, starts sandboxed.
Do I still need a sandbox if I have hooks?
They cover different things. A hook checks a command before it starts and can explain itself to the agent. A sandbox limits what any process can do once running. For unattended work, use both.
Can a sandboxed agent still delete my project?
Yes. The project folder is writable inside every kind of sandbox, because the agent has to be able to work there. That's what commits, worktrees and snapshots are for.