The Three Approval Modes, Explained

on-request, untrusted, and never answer a question sandbox mode doesn't: not what Codex is technically allowed to do, but when it has to stop and ask you first before doing it.

On-request: the interactive default

on-request prompts before Codex does anything outside the sandbox's own boundary — outside the workspace under workspace-write, or for a network call that isn't otherwise enabled. Inside the boundary, ordinary reads, edits and commands proceed without a prompt; it's specifically the edge of what the sandbox permits where this mode asks first. This is the right default for most interactive, human-supervised sessions, where you're present and able to answer a prompt promptly when it appears.

Untrusted: narrower automatic execution

untrusted shrinks the set of things that happen automatically to commands Codex already recognizes as safe, prompting for everything else — a stricter posture than on-request, useful when you want more edits and commands to proceed without interruption but aren't ready to hand over blanket automatic execution of anything the sandbox would technically permit. The practical effect is fewer surprises: an unfamiliar or unusual command still gets a check, even one that's technically within the sandbox's boundary.

Never: no prompting, with one standing exception

never removes prompting for everything the sandbox permits — the mode built for genuinely unattended contexts like CI, where nobody is present to answer a prompt anyway. The one thing that doesn't go away under never: a destructive-annotated MCP tool call still requires approval, unconditionally. Any pipeline built around never for full automation needs to account for that possibility — a stalled approval with nobody present to answer it — rather than assuming never guarantees the pipeline runs start to finish with zero interruption.

Why "never" isn't actually a safety downgrade from the other two

It's tempting to read never as simply "less safe" than the other two modes, but that framing misses what it's actually for — a genuinely unattended context where there's no human available to answer a prompt regardless of approval mode, so a mode that keeps prompting anyway wouldn't add safety, it would just produce a pipeline that hangs waiting for an answer nobody's there to give. never paired with a tightly scoped read-only sandbox, for instance, is a genuinely conservative combination — it's the pairing with a permissive sandbox mode that deserves real scrutiny, not the approval mode in isolation.

Approval mode and sandbox mode are independent dials

It's a common mistake to think of these three approval modes as inherently tied to specific sandbox modes — they're not. never can pair with read-only for a strictly read-only CI check, or with workspace-write for a pipeline that's expected to make actual changes unattended, and the risk profile of those two pairings is very different even though both use the same approval mode. Reasoning about the two dials separately, rather than assuming a fixed pairing, is what lets you build the specific combination a given task actually needs.

Switching approval mode mid-session

/permissions adjusts approval mode (and sandbox mode) without restarting a session — useful for starting conservatively under on-request and loosening to untrusted once you've seen a session behave reasonably for a while, or the reverse, tightening back to on-request if a session starts doing something you want closer oversight of. Treating the mode as adjustable in-session, rather than a fixed choice made once at launch, is a more realistic way to actually use these three options.

Checking which mode is active before assuming it

The same way sandbox mode is worth confirming with /status rather than assumed, approval mode deserves the same check — particularly before starting a task you expect to run largely unattended, where discovering partway through that you're actually under on-request (and the session has been silently waiting on a prompt) wastes real time you could have spent noticing and answering it sooner.

Picking the right mode for a task, not a habit

The most common mistake with approval modes isn't picking a technically wrong one — every combination is technically valid for some task — it's using the same mode reflexively for every task regardless of what that specific task actually calls for. A quick, well-understood edit and a long unattended batch job have genuinely different appropriate approval postures, and treating the choice as a per-task decision rather than a fixed personal default is what actually gets the safety and convenience tradeoff right each time.

How approval fatigue actually happens

A session under on-request that keeps prompting for genuinely low-risk, repetitive actions trains you, over time, to approve without really reading the prompt — the exact failure mode approval prompts exist to prevent. If a specific session is generating a lot of prompts for things you'd approve every single time without a second thought, that's a signal worth acting on: either the task's scope is broader than the sandbox boundary comfortably allows, or untrusted (letting known-safe commands proceed automatically) is a better fit than on-request for this specific, repetitive workflow. Treating a wave of prompts as noise to click through, rather than as a signal to reconsider the mode, is how a real approval eventually gets rubber-stamped by habit.

Approval prompts as a debugging signal, not just a safety gate

A prompt appearing where you didn't expect one is often the first sign something about a task's scope has drifted beyond what you originally intended — Codex reaching outside the workspace boundary, or attempting a command you wouldn't have expected it to need for the task at hand. Reading an unexpected prompt closely, rather than approving it quickly to keep the session moving, occasionally catches a session that's about to do something you'd actually want to stop and reconsider, independent of whether the action itself would technically have been safe.

A note on approval mode and team conventions

For a team standardizing how Codex gets used across projects, agreeing on a default approval mode for interactive work and a separate one for CI is worth writing down explicitly, the same way a team might standardize on a linter configuration — not because every developer needs to use the identical setting for every task, but so that "which mode should I use here" has a documented starting answer rather than each person guessing independently and ending up with inconsistent habits across the team.