Why Approvals and Sandbox Are Separate Settings

It would be simpler, on the surface, to have one setting: how permissive should this session be, on a single scale from cautious to unrestricted. Codex doesn't work that way, and the choice to keep sandbox mode and approval mode as two independent dials rather than one combined slider is worth understanding on its own terms, because collapsing them in your own mental model is a reliable way to misconfigure both.

Two genuinely different questions

Sandbox mode answers "what is this session technically capable of doing" — reading, editing inside a workspace, running commands, reaching the network, all bounded by which of the three sandbox modes is active. Approval mode answers a completely separate question: "when does the session have to stop and check with me before doing something it's technically capable of." A session can be broadly capable and still ask permission for almost everything it does; a session can be narrowly capable and never ask permission for anything, because there's nothing within its narrow capability worth asking about.

Why conflating them produces bad configurations

Treat the two as one scale, and you end up either over-restricting capability to compensate for wanting fewer prompts, or over-permitting capability because you wanted a session to act more autonomously and didn't realize approval mode was the actual lever for that. Neither compromise gets you what you actually wanted. A CI pipeline that needs to write files but shouldn't be interrupted by prompts needs workspace-write paired with never — two separate, deliberate choices. Collapsing them into a single "how autonomous should this be" question obscures that these are answers to two different questions, not one.

The genuinely orthogonal combinations this makes possible

Because the two dials are independent, every combination is a real, meaningful configuration, not just theoretically possible. Read-only with constant prompting is maximally cautious — safe reads, and even those get confirmed. Read-only with never-prompt is the CI-appropriate profile this site covers separately — nothing destructive is even possible, so removing prompts costs nothing in safety. Workspace-write with on-request prompting is the ordinary interactive default. Workspace-write with never-prompt is a genuinely more permissive unattended posture, worth real scrutiny before choosing it. Each of these four is a legitimate, distinct configuration a real task might call for — a single combined scale would have to approximate all four with far fewer actual settings.

What neither dial can override

It's worth stating plainly that this two-dial design has one deliberate exception baked into it: a destructive-annotated MCP tool call requires approval regardless of what either dial is set to. That's not a third dial — it's a hard floor underneath both of them, there specifically so that no combination of sandbox permissiveness and approval leniency can produce a session that silently performs a destructive, tool-flagged action with zero human check at all.

Why this design choice reflects something true about risk generally

Capability and oversight are genuinely different axes of risk in most systems, not just this one — a highly capable system with tight oversight can be safer in practice than a narrowly capable system nobody's watching, and the reverse holds too depending on what specifically goes wrong. Codex's two-dial design is, in effect, an acknowledgment that collapsing "what can this do" and "how closely is a human watching" into one number loses real information a careful operator would want to control independently.

What this means for how you should actually configure a session

Rather than reaching for a single mental "how much do I trust this task" judgment and picking one preset, it's worth asking the two questions separately every time: what does this specific task actually need to be capable of, and separately, how much do I want to be interrupted while it's doing that. The five named presets this site documents elsewhere are convenient shortcuts through common combinations of both answers — but understanding the two dials individually is what lets you recognize when a task's actual needs don't match any of the named presets, and build the specific combination it does need instead.

A habit worth building from this understanding

Whenever a session behaves in a way you didn't expect — either prompting more than felt necessary, or doing something you wish it had asked about first — it's worth diagnosing which of the two dials was actually responsible before changing anything. A session that prompted too much needs an approval-mode adjustment, not necessarily a broader sandbox. A session that did something you wish it hadn't needs a narrower sandbox, not necessarily stricter approval. Fixing the wrong dial doesn't just fail to solve the problem — it can introduce a new one in the direction you weren't trying to change.

An analogy that makes the distinction stick

Think of sandbox mode as the locks on the doors of a building, and approval mode as whether a receptionist checks in with you before letting someone through a door that is unlocked. A building with every door unlocked and a receptionist checking in constantly is annoying but not unsafe in the way an unlocked building with no receptionist at all would be. A building with every door locked doesn't need a receptionist checking in at all, because there's nothing to get through regardless. The two mechanisms address different failure modes, and a security policy that only tuned one of them — locks or reception, never both together — would be missing half the picture. Codex's two independent dials are the same idea applied to an agentic session.

Why documentation for this feature tends to undersell the distinction

Most quick-start guides for tools like this default to teaching the named presets — Auto, CI, and so on — because presets are faster to get someone productive with, and for a lot of users that's genuinely sufficient. The tradeoff is that presets can obscure the two-dial structure underneath them, leaving a reader able to invoke the right preset by name without actually understanding why it's built the way it is, or how to construct a different combination when a task's needs fall outside what any named preset covers. Understanding the two dials individually is what closes that gap, and it's worth the extra few minutes over just memorizing preset names.