The post starts from Claude Code’s permission-based model: by default the agent is read-only and asks before modifying anything or running most commands, with a few safe commands such as echo or cat auto-allowed. It argues that constantly clicking “approve” both slows development and can lead to Approval Fatigue, where users stop paying close attention to what they approve — making development less safe rather than more.
Its answer is Sandboxing: pre-defined boundaries inside which Claude can work freely instead of asking permission for each action. The post introduces two features built on this idea. The first is a sandboxed bash tool, running on a new sandbox runtime (Sandbox Runtime) released as a beta research preview and as open source. The second is Claude Code for web, which runs each Claude Code session in an isolated sandbox in the cloud. Anthropic reports that in its internal usage sandboxing safely reduced permission prompts by 84%.
Key Points
- The sandboxing approach enforces two boundaries built on operating-system-level features: filesystem isolation, so Claude can only access or modify specific directories, and network isolation, so it can only connect to approved servers.
- Effective sandboxing is said to require both: without network isolation a compromised agent could exfiltrate files such as SSH keys, and without filesystem isolation it could escape the sandbox and gain network access.
- The motivating threat is Prompt injection: filesystem isolation stops a prompt-injected Claude from modifying sensitive system files, and network isolation stops it from leaking information or downloading malware.
- The sandbox runtime lets users define which directories and network hosts an agent can access without spinning up and managing a container, and can sandbox arbitrary processes, agents and MCP servers.
- In Claude Code it sandboxes the bash tool: inside the sandbox commands run without permission prompts, and an attempt to reach something outside it notifies the user, who can choose whether to allow it.
- Enforcement uses OS primitives — Linux bubblewrap and macOS seatbelt — and covers not only Claude Code’s direct actions but any scripts, programs or subprocesses a command spawns.
- By default the bash sandbox allows reads and writes in the current working directory and blocks modification of files outside it; network access goes only through a unix domain socket connected to a proxy outside the sandbox, which restricts reachable domains and asks the user about newly requested ones. Both sides are configurable.
- The post claims that sandboxing ensures even a successful prompt injection is fully isolated, so a compromised Claude Code cannot steal SSH keys or phone home to an attacker’s server.
- Claude Code on the web is designed so that sensitive credentials such as git credentials or signing keys are never inside the sandbox with Claude; a custom proxy handles git interactions, verifies a scoped credential and the content of each interaction (for example, pushing only to the configured branch), then attaches the real token before forwarding to GitHub.
- Anthropic open-sourced the sandbox feature and recommends that others building agents consider adopting it.
Context
This is a vendor’s own launch write-up for its own features: the 84% figure is from Anthropic’s internal usage, and the security claims describe the design as its builders intend it. The argument it makes — that fewer prompts inside a hard boundary is safer than many prompts without one — reappears in this wiki’s account of Approval Fatigue and in other writing on Sandboxing, where the same design is discussed by third parties.