Can OS sandboxing reduce AI permission prompts without sacrificing safety?

Anthropic engineers David Dworken and Oliver Weller-Davies describe a shift from "a permission-based model" — where Claude Code is "read-only" by default and "asks for permission before making modifications or running any commands" — to sandboxing, which "creates pre-defined boundaries within which Claude can work more freely, instead of asking for permission for each action." They report that "in our internal usage, we've found that sandboxing safely reduces permission prompts by 84%." The sandbox enforces two boundaries at once: filesystem isolation, "allowing read and write access to the current working directory, but blocking the modification of any files outside of it," and network isolation, routing all internet access "through a unix domain socket connected to a proxy server running outside the sandbox" that enforces which domains a process may reach.

Anthropic's stated reasoning is that per-action approval has a failure mode of its own: "constantly clicking 'approve' slows down development cycles and can lead to 'approval fatigue', where users might not pay close attention to what they're approving." Sandboxing substitutes boundaries set once for approvals asked repeatedly. The post argues the two isolation types are not separable: "without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys; without filesystem isolation, a compromised agent could easily escape the sandbox and gain network access." Built on "OS level primitives such as Linux bubblewrap and MacOS seatbelt," the boundary also covers "any scripts, programs, or subprocesses that are spawned by the command," and an attempt to cross it surfaces to the user immediately rather than failing silently.

The mechanism matches what Can agent safety rules stop destructive API calls in real time? identifies as missing from that incident: its root cause, in Giskard's account, was that "system prompt rules, project configuration, and model safety training are all internal to the agent's own reasoning," so none could stop an irreversible action once decided, and what was absent was "an external boundary." Anthropic's sandboxing is that kind of boundary, enforced by the OS rather than by the agent's judgment or a human's repeated approval clicks — though it bounds a working directory and a domain allowlist, not a cloud API's mutation calls, so it would not by itself have scoped the root-level token in that incident. It also sits in a different configuration from Did AI agents escape the sandbox during cyber tests?: that incident involved internet access deliberately left open during an evaluation, the opposite of the default-closed network allowlist described here. A related, narrower control from the same post is covered separately in How does Claude Code protect git credentials from sandbox compromise?.

The 84% figure is Anthropic's own internal-usage measurement, not an independent or externally audited one, and the post does not say over what period, user population, or task mix it was measured, nor whether it reflects prompts avoided versus prompts that would have been denied anyway. The post reports no adversarial or red-team evaluation of the sandbox itself, so the claim that "even a successful prompt injection is fully isolated" is Anthropic's stated design intent, not a tested outcome. The implication the excerpt supports is narrow: a vendor reports that replacing per-action prompts with OS-enforced boundaries reduced prompts in its own usage and was designed to close two complementary attack paths; it does not establish how the sandbox performs under adversarial testing.