The sandbox is a technical execution boundary, and in Codex it is enforced by the operating system, not by a mere request to the model. Local commands in the CLI, the IDE extension and the desktop app run in an OS-enforced sandbox. The mechanism depends on the platform: macOS uses Seatbelt, Linux and WSL use bubblewrap and seccomp with compatibility paths, native Windows an elevated or a weaker unelevated implementation. Understanding this matters: the strength of the boundary depends on the platform, and the Windows implementation is not equal to Linux in strictness.

Inside the sandbox there is protection that works even where writing is generally allowed. Even inside a writable root, .git, .agents and .codex are separately protected. This is not accidental but a conscious boundary: it prevents the agent from quietly changing the repository metadata, its own instructions and policy. Otherwise the agent, having the right to write to the project, could rewrite the rules by which it itself works - and that is an undermining of the whole trust model from within.

Hence an important rule about extending access. If the agent needs access to an additional directory, it is added narrowly - via --add-dir or a profile - rather than removing the sandbox entirely. The difference is fundamental: a narrow extension opens exactly what the task needs, whereas disabling the sandbox opens everything at once. The temptation to "just turn it off so it does not get in the way" is strong, but it is exactly what turns a controllable boundary into its absence, and a reversible setting into an irreversible risk.

It helps to see the base sandbox setup in full once. Below is the workspace-write mode with network access off and web_search in cached mode. This configuration allows the cached search tool but does not give npm, tests or shell scripts network egress. You return to this form when setting the working boundary: it shows that file access and network access are separate axes, and one does not enable the other automatically.

The network axis needs separate attention, because there is much confusion around it. An allowed cached search tool is not the same as network egress for spawned commands. To limit an already-enabled network by destinations, a network proxy policy is used; meanwhile the proxy flag itself does not enable the network. This separation is worth remembering: enabling search, enabling the network and limiting the network by domains are three different actions, and confusing them means misjudging what the agent can actually send out.