Claude Code Gets Sandboxing: 84% Fewer Permission Prompts

TL;DR

• Anthropic shipped sandboxing for Claude Code that cuts permission prompts by 84% in internal testing
• Two-layer isolation: filesystem boundaries prevent system file access, network controls block unauthorized connections
• New sandboxed bash tool runs commands autonomously within defined limits — no container overhead
• Claude Code on the web launches with cloud-based sandboxing and a custom git proxy that keeps credentials outside the sandbox
• The sandbox runtime is open source — other agent builders can integrate it now

The Big Picture

Claude Code's permission model has a problem. Every file edit, every command execution triggers an approval prompt. The intent is security — prevent a prompt-injected Claude from trashing your system. The reality is approval fatigue. Developers click through prompts without reading them, which defeats the purpose.

Anthropic's solution is sandboxing. Not the Docker kind that adds container management overhead. OS-level isolation using Linux bubblewrap and macOS seatbelt that creates hard boundaries around what Claude can touch. Inside those boundaries, Claude runs autonomously. Outside them, you get a prompt.

The result: 84% fewer permission prompts in Anthropic's internal usage. More importantly, the prompts you do see actually matter — they're boundary violations, not routine operations. This is the same principle behind Anthropic's long-running agent work, where reducing friction lets agents operate more effectively without sacrificing control.

Two features ship today: a sandboxed bash tool for local development, and Claude Code on the web that runs entirely in isolated cloud sandboxes. Both tackle the same problem — how do you give an AI agent enough autonomy to be useful without handing it the keys to your entire system?

How It Works

The sandbox enforces two types of isolation. Filesystem isolation restricts Claude to specific directories — typically your current working directory. Network isolation blocks all internet access except through a proxy server that enforces domain allowlists. You need both. Filesystem isolation alone doesn't stop a compromised agent from exfiltrating your SSH keys over the network. Network isolation alone doesn't prevent an agent from modifying system files to gain network access later.

The implementation uses OS primitives, not containers. On Linux, it's bubblewrap. On macOS, it's seatbelt. These are kernel-level enforcement mechanisms. When Claude spawns a subprocess or runs a script, the restrictions apply to everything in that execution tree. A bash script that calls curl can't bypass the network proxy. A Python script that tries to write to /etc gets blocked at the syscall level.

The network proxy is the clever part. Inside the sandbox, processes connect to a unix domain socket. That socket connects to a proxy server running outside the sandbox. The proxy checks every outbound connection against your configured allowlist. New domains trigger a permission prompt. You can customize the proxy to enforce arbitrary rules — block all connections, allow only specific API endpoints, log everything for audit purposes.

Configuration is straightforward. Run /sandbox in Claude Code and you get a default setup: read-write access to your working directory, no network access. You can whitelist specific paths or domains. The sandbox persists across sessions, so you configure it once per project.

For Claude Code on the web, the architecture is different. Each session runs in an isolated cloud sandbox with full server access. The security model assumes the sandbox is compromised from the start. Sensitive credentials never enter the sandbox. Git operations route through a custom proxy that validates every interaction.

The git proxy works like this: Inside the sandbox, git authenticates with a scoped credential that only the proxy understands. When git pushes code, the proxy verifies the credential, checks the target branch against your configuration, then attaches the real GitHub token before forwarding the request. The sandbox never sees your actual credentials. Even if a prompt injection convinces Claude to run git push --force origin main, the proxy blocks it if you configured push access only to a feature branch.

This is defense in depth. The sandbox prevents filesystem and network abuse. The git proxy prevents credential theft and unauthorized repository access. A successful prompt injection is contained — it can't steal secrets, can't phone home, can't persist beyond the session.

Anthropic open sourced the sandbox runtime. It's available as a research preview on GitHub. The code is designed for integration into other agent systems. If you're building autonomous agents that execute code, you should be using something like this. The alternative is either constant permission prompts or accepting the risk of compromised agents with full system access.

What This Changes For Developers

The immediate impact is workflow speed. Eighty-four percent fewer prompts means Claude Code feels more like pair programming and less like babysitting. You define boundaries once, then let Claude work. When a prompt does appear, it's signal, not noise — Claude is trying to access something outside the sandbox, and you need to decide if that's legitimate.

The security model shifts from "approve every action" to "define safe zones." This is better security architecture. Approval fatigue is real. Developers get tired of clicking "allow" and stop reading what they're approving. Sandboxing makes the security boundary explicit and enforced by the OS, not by user vigilance.

For teams building on Claude Code, sandboxing enables new workflows. You can let Claude run test suites, start development servers, execute build scripts — all without manual approval for each command. The filesystem isolation means Claude can't accidentally modify configuration files outside your project directory. The network isolation means a compromised agent can't exfiltrate data to an attacker-controlled server.

Claude Code on the web changes the deployment model. You don't need local setup. You don't need to worry about Claude accessing your local filesystem or network. Everything runs in a disposable cloud sandbox. This is particularly useful for onboarding new developers, running untrusted code, or working from locked-down environments where you can't install local agents.

The git proxy architecture is worth stealing for other agent systems. Credentials are the highest-value target for prompt injection attacks. Keeping them outside the sandbox and routing all authenticated operations through a validation proxy is a pattern that applies beyond git — API keys, database credentials, cloud provider tokens all benefit from the same approach.

Try It Yourself

To enable sandboxing in Claude Code, run the /sandbox command in your Claude Code session. This activates the default sandbox configuration with filesystem isolation to your working directory and network isolation through the proxy.

For custom configuration, check Anthropic's sandboxing documentation. You can whitelist specific file paths or network domains based on your project requirements.

To try Claude Code on the web, go to claude.com/code. Each session runs in an isolated cloud sandbox with the git proxy automatically configured.

If you're building your own agent systems, the sandbox runtime is available at github.com/anthropic-experimental/sandbox-runtime. The repository includes implementation details for both Linux and macOS, plus the network proxy code.

The Bottom Line

Use sandboxing if you're running Claude Code on any project where prompt injection is a realistic threat — which is every project that processes external input. The 84% reduction in permission prompts isn't just convenience, it's better security through reduced approval fatigue.

Skip Claude Code on the web if you need access to local services or databases that can't be exposed over the internet. The cloud sandbox isolation means you can't connect to localhost services. Stick with local Claude Code with sandboxing enabled for those workflows.

The real opportunity here is the open source sandbox runtime. If you're building autonomous agents that execute code, you need isolation. Containers are overkill for most use cases — they're slow to spin up and add operational complexity. OS-level sandboxing gives you the security boundary without the overhead. Anthropic just handed you production-ready code that solves this problem. Use it.

Source: Anthropic