The sandbox is easy to confuse with one more line in the prompt - a polite request to the agent to "stay within bounds". That is a fundamental mistake. The sandbox is not an instruction the model may or may not obey but an OS-level system boundary: what a process may write and what it may reach over the network is decided by the operating system, not by the text of the task.
The naive move is to rely on obedience. Write in the rules "do not touch anything outside src, do not go to the network" and consider that enough, because the agent usually obeys. The expectation: a good instruction is equivalent to a restriction. On a calm task it looks that way - until the first case where the model interprets the frame differently.
It breaks on the nature of an instruction: it is probabilistic, while a boundary must be deterministic. A prompt can be bypassed by a reasoning error, an unlucky phrasing or an injection from the data; a sandbox cannot be bypassed by reasoning - it is outside the agent's process. Writable paths are derived from the granted Write scopes plus the workspace directory, everything else is read-only; and paths that fall under Read deny are hidden from sandboxed commands entirely. This is not something the agent promises to honor - it is something it physically cannot violate.
From this system nature follows an important behavior on failure. If the sandbox cannot be brought up - for instance, the isolation tools are absent on the platform - the CLI must fail closed: refuse to start rather than silently continue without isolation. That is the right side to err on: better not to start than to start defenseless. On Windows OS-level sandboxing is unsupported and a session with it hard-fails; on Linux it needs bubblewrap (bwrap) and socat. The boundary honestly says "I cannot" instead of pretending it is there.
The sandbox filters the network by domains, and the patterns have their own precision. example.com - exact match only; *.example.com - subdomains without the apex itself; **.example.com - both the apex and all subdomains. Deny takes precedence over allow. And right away a dated caveat: the documentation marks network filtering as unstable, so timing and details are checked with Cognition and against the current page, not against this text. Building a strict security policy on it is premature. Until it stabilizes, it is wiser to treat network filtering as a convenience rather than a line of defense: what must not leave at all is more reliably kept out of the context than trusted to a domain list.
How this relates to permission mode. Autonomous mode is available only with a sandbox and works like Accept Edits with the added ability to run any shell command, but inside the OS boundary. So the boldness of shell here is paid for not with trust but with isolation: the command runs automatically, but in a cage where only writable paths and allowed domains are available to it.
And right here a deliberate boundary that is important not to overlook. In Autonomous, shell and fetch run automatically inside the sandbox, but the edit and write tools work in the agent's own process and still raise a prompt. This is not an oversight but a design: editing a file is a direct change to your working tree, and it is kept under approval even where shell is already released. Autonomy is given to execution in the cage, but not to direct writing past it.
Why both things are needed - permission rules and the sandbox - rather than one. They cover different classes of failure. Permission rules are a policy of intent: what the agent is even supposed to ask for and do. The sandbox is physical insurance for when intent fails: an error, a bypass, an injection. The rules say "do not ask for the unnecessary", the cage adds "and if you ask and it slips through - you still cannot". One layer without the other leaves either an uncheckable promise or a ban without insurance.
You must verify the sandbox systematically, not by the agent's word. Make sure that a write outside the writable paths really does not pass, not just that "the agent never tried". Check that a path from Read deny is invisible to a sandboxed command. If the platform cannot bear isolation, expect an honest refusal to start rather than silent work - and if you saw work without a sandbox where it is required, that is a signal to investigate, not to continue.
The typical failures are about trusting an instruction instead of a boundary. "The agent went out of bounds even though I forbade it in the rules" - rules are a request, not a sandbox. "I thought the sandbox protects the network" - filtering is marked unstable, it is early to rely on it. "Autonomous, yet it asked about an edit" - edit is deliberately outside auto-execution. "It ran without isolation" - meaning the sandbox was not required, or fail-closed was bypassed. The sign is the same: the agent's safety is explained by what it was told rather than by what is systemically available to it. Separate the request from the boundary, and the picture of risks becomes honest.