Codex uses two separate settings. The sandbox mode sets technical boundaries on what spawned commands can touch. The approval policy decides when the agent stops to ask you. Mixing them up is the usual mistake, and it can leave an agent with far more freedom than you meant to give it, so set each deliberately.
Sandbox modes
OpenAI's documentation lists three values for the sandbox mode setting:
- read-only: the agent can inspect files but cannot edit files or run commands without approval.
- workspace-write: the default low friction mode for local work. The agent reads files, edits within the workspace and runs routine local commands inside that boundary.
- danger-full-access: no sandbox restrictions, so no filesystem or network boundary. The page says to use it only when you want full access.
Approval policies
The page names two selectable policies:
- on-request: the agent works inside the sandbox and asks when it needs to go beyond it.
- never: no approval prompts.
It notes that the untrusted policy is no longer selectable. In the permissions menu, full access is paired with the never policy. Combining full access with never means nothing limits the agent and nothing asks you, so reserve it for disposable environments.
How the boundary is enforced
- macOS: the built-in Seatbelt framework.
- Linux and WSL2: bubblewrap. Codex uses the first bwrap on the path and falls back to a bundled helper that needs unprivileged user namespaces. Ubuntu 24.04 may need an AppArmor profile.
- Native Windows: a native Windows sandbox.
Boundaries apply to spawned commands such as git, package managers and test runners, not only built-in file operations.
Extending without removing the sandbox
A writable roots setting extends writable directories while keeping the sandbox. An approvals reviewer setting can be user (the default) or auto review, and the page says automatic review does not change the sandbox boundary. Rules can allow, prompt or forbid specific command prefixes outside the sandbox.
What the page does not say
The sandboxing page did not state the default network setting for the local sandbox, so check your version. It does say that for ChatGPT Work, network access is off by default and limited to a managed allowlist unless public internet access is turned on.
A sane starting point
Use workspace-write with on-request. Add writable roots for specific folders. Keep full access for containers you can throw away. The same logic applies to other coding agents, as in Claude Code bash sandbox: what it covers and misses.
Safeguard's free dependency scan is at gold.safeguard.sh/scan.
Reading the pairing as a matrix
Read-only with on-request is the most cautious pairing: the agent looks around and asks before anything changes. Workspace-write with on-request lets routine work flow while still stopping for anything outside the workspace. Full access with never is the other end, with no boundary and no prompts. Most teams should sit near the middle, and write down which repositories, if any, are allowed to use the extreme setting.
Quick check
Is the sandbox the same as the approval policy?
No. The sandbox sets technical boundaries. The approval policy decides when the agent asks.
Which mode removes all boundaries?
danger-full-access, which has no filesystem or network boundary.
Sources
Last reviewed: 19 October 2026.
