TL;DRDon't conflate the sandbox with approvals: one fences the territory, the other decides when it must ask permission. This walks both layers into a working setup — workspace-write plus on-failure to start — and a five-minute self-test.
Sources SOURCES
Distilled from public community discussions. This page only breaks them down and verifies — it never reposts the original; opinions belong to their authors.
Facts FACTS
Check these claims against the listed sources. For allowance mechanics, first-party account displays outrank community summaries.
- Sandbox and approvals are two independent mechanisms: the sandbox constrains which files the agent can read and write; the approval policy decides when it pauses to ask a human.
- The workspace-write sandbox on macOS is implemented with Seatbelt — writes inside the workspace pass, writes outside it get blocked.
--yolo(--dangerously-bypass-approvals-and-sandbox) switches off both the sandbox and approval layers at once; in official terms that's the highest-risk mode.- Verified behavior: under the on-failure approval policy, commands that fail in the sandbox still request approval — an automatic tier is not the same as fully unattended. There's a corresponding record on GitHub.
Concepts CONCEPTS
Not everything said in a community thread is a fact — each concept carries its nature label. Read the label first.
The execution-environment layer limiting the agent's file and system access. The workspace-write tier allows writes inside the workspace and blocks everything else; on macOS the machinery is Seatbelt.
A second layer independent of the sandbox, deciding when the agent pauses for human confirmation; on-failure means execute first, and ask only when something fails.
The common framework in security write-ups: treat read-only, workspace-write, and full-disk access as three distinct risk tiers and configure each deliberately. The tiering idea is consensus advice, not an official mandate, and the tiers give teams a shared vocabulary for what's allowed where.
A common misconception: configuring the sandbox means you can ignore approvals, or the other way around. Each layer governs its own half, and loosening either one alone changes the overall risk shape. Configuring both, deliberately, is the whole game.
Step-by-step SOP STEP BY STEP
- 01Recognize the two layers
The sandbox governs "what it can touch"; approvals govern "when it asks." Before touching any config, write down the workspace scope and the never-touch list for this project — that list is the spec the rest of the SOP configures against.
- 02Start on the default tier
Run daily sessions with
codex --full-auto. The shared understanding in the community and official docs: it maps to the workspace-write sandbox combined with on-failure approvals. - 03Pin the defaults
Tired of typing flags every time? Edit
~/.codex/config.tomland set approval_policy and sandbox_mode as your project defaults. - 04Five-minute self-test
Ask it to run a command that must write outside the workspace — creating a temp file outside the repo works — and watch what happens: blocked by the sandbox first, then an approval prompt. That's on-failure behaving as designed. If the command sails through with no prompt at all, stop and check your tiers before continuing.
- 05Set the red lines
Write the never-loosen list: secrets and credentials, production configs, global installs, and irreversible outbound operations (publish, delete) stay manual. Always. These are the items you don't negotiate with yourself about late on a Friday.
- 06Confirm in-session
Glance at the tier shown in the UI when you start work; if you're unsure which switching commands this version supports, type
/helpand check. - 07Write it into team convention
Put the recommended tiers and the red-line list into the README or AGENTS.md, so the rules travel with the repo instead of anyone's memory.
Keep reading NEXT
Want today's verdict? Back to the live radar.