If you’ve been using Claude Code for a while, you’ve probably developed a somewhat complicated relationship with its permission system. Every bash command requires approval, every file write needs a click. It’s the right default - you don’t want an AI agent running arbitrary commands on your machine unsupervised - but in practice it leads to approval fatigue. You end up clicking “approve” on autopilot, which kind of defeats the purpose.
This is exactly the problem that Claude Code’s native sandboxing feature aims to solve, and it does so in a way that I think is genuinely well thought out.
How it works
Rather than asking permission for each command, sandboxing defines boundaries upfront. Within those boundaries, Claude Code can work freely. Step outside them, and the operation is blocked at the OS level before anything happens.
The implementation uses actual operating system security primitives rather than application-level checks. On macOS it leverages Seatbelt , on Linux it uses bubblewrap . This is important because it means the restrictions apply to everything - not just the commands Claude runs directly, but all child processes as well. If Claude runs an npm install that triggers a postinstall script that tries to phone home, the network restriction catches that too.
There are two layers of isolation:
Filesystem isolation restricts write access to the current working directory and its subdirectories. Claude Code can read files elsewhere on your system (useful for referencing system libraries and such), but it cannot modify anything outside your project. You can grant additional write paths if needed:
1{
2 "sandbox": {
3 "enabled": true,
4 "filesystem": {
5 "allowWrite": ["~/.kube", "//tmp/build"]
6 }
7 }
8}
Network isolation routes all traffic through a proxy that only allows approved domains. When Claude Code (or any subprocess it spawns) tries to reach a domain that hasn’t been approved, the request is blocked and you get a notification asking whether to allow it.
Why both layers matter
Effective sandboxing requires both filesystem and network isolation working together. Without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys. Without filesystem isolation, it could backdoor system resources to gain network access later. Neither layer on its own is sufficient.
Enabling it
Getting started is straightforward. Run /sandbox in Claude Code and pick a mode. On macOS it works out of the box. On Linux you’ll need bubblewrap and socat:
1sudo apt-get install bubblewrap socat
There are two modes: auto-allow (sandboxed commands run without prompts, non-sandboxable commands fall back to the regular permission flow) and regular permissions (all commands still require approval, but are sandboxed regardless). Auto-allow is where the productivity gain lives - it’s the mode that eliminates the approval fatigue while still keeping you protected.
Not everything can be sandboxed
Some tools are inherently incompatible. Docker is the obvious one - it needs system-level access that doesn’t play well with sandbox restrictions. You can exclude specific commands:
1{
2 "sandbox": {
3 "excludedCommands": ["docker"]
4 }
5}
There’s also an escape hatch: when a command fails due to sandbox restrictions, Claude Code can retry it outside the sandbox, but only with your explicit approval through the normal permission flow. If you’d rather not have that option at all, set "allowUnsandboxedCommands": false.
Open source
What I think is a nice touch is that the sandbox runtime is available as an open source npm package . You can use it in your own agent projects, or even to sandbox other programs entirely unrelated to Claude:
1npx @anthropic-ai/sandbox-runtime <command-to-sandbox>
Why this matters
The security model of “ask permission for everything” doesn’t scale. As AI agents take on longer, more complex tasks, the number of approval prompts grows to the point where they become noise. Sandboxing is a more sustainable approach: define the boundaries once, then let the agent work within them. If it tries to step outside, the operating system itself prevents it.
It’s not a silver bullet - you still need to be thoughtful about which domains you allow and which paths you open up for writes - but it’s a significant step towards making AI-assisted development both more productive and more secure at the same time. That’s a combination that doesn’t come along very often.