The Three Sandbox Modes, Explained

Three names, three genuinely different boundaries — read-only, workspace-write, and danger-full-access — and understanding what each one actually restricts is the foundation everything else about Codex's safety posture builds on.

Read-only: the narrowest boundary

A session running under read-only can read files and answer questions about them, and that's the entire scope — no edits, no command execution beyond what's needed to read and analyze. This is the right mode for anything where you want Codex's judgment or analysis without any risk of it changing anything, and it's also the mode a non-version-controlled directory starts in by default until explicitly trusted, a detail worth knowing if a fresh project seems unexpectedly locked down.

Workspace-write: the ordinary working default

workspace-write permits reading, editing, and running commands, scoped to the current project directory — the mode most actual day-to-day work happens under. Two details worth knowing well before relying on this mode: network access is off by default and needs to be explicitly enabled, and certain paths inside the workspace — .git, .agents, .codex — stay protected recursively regardless of this mode being otherwise permissive, including when .git is a worktree's pointer file rather than a literal directory.

Danger-full-access: the mode that removes the workspace boundary

This is the one mode where the sandbox stops being the thing keeping a session's actions contained to the project directory — full access genuinely means full access, not "workspace-write plus a bit more." It's a real, published option, but it's worth treating as a deliberate, occasional choice for a specific, well-understood task rather than a default you reach for out of impatience with approval prompts elsewhere.

Why three modes instead of a single sliding scale

A single permission slider would hide the fact that these are qualitatively different boundaries, not points on one continuum — read-only versus workspace-write is "can it change anything at all," while workspace-write versus danger-full-access is "does the workspace boundary still exist as a concept." Naming them as three distinct modes, rather than a numeric scale, forces a deliberate choice about which kind of boundary you actually want rather than an implicit one about how far along a scale to go.

Combining sandbox mode with approval mode

Sandbox mode alone doesn't determine whether Codex prompts you before acting — that's the separate approval-mode dial, covered on its own page. The two combine into the presets most people actually use day to day: the default Auto posture pairs workspace-write with on-request approval, for instance. Understanding each dial individually is what lets you deviate from the presets deliberately when a specific task calls for a different combination than the defaults offer.

Choosing a mode for a specific task, not a permanent default

The most defensible way to use these three modes isn't picking one and leaving it for every session — it's starting a task in the narrowest mode that could plausibly get the job done, and deliberately widening it only once you've confirmed the task actually needs more. A quick investigation or question-answering task rarely needs more than read-only; an edit-and-test loop needs workspace-write; genuine full access should be rare enough that reaching for it is a conscious decision each time, not a habit.

What none of the three modes override

Regardless of which sandbox mode is active, a destructive-annotated MCP tool call still requires approval — sandbox mode governs what Codex can do technically, not whether a specific dangerous-looking action still gets a human check first. That distinction is worth keeping in mind especially under danger-full-access, where it's easy to assume every safety mechanism has been switched off; this particular one hasn't.

Checking which mode a session is actually running under

/status reports the active sandbox mode for a running session — worth checking explicitly rather than assuming, especially if a session was started with a flag you don't fully remember, or inherited its configuration from a script or wrapper you didn't write yourself. Confirming the mode before doing anything sensitive in a session is a habit worth having, the same way checking which model answered a request is worth confirming before budgeting against it.

How trust posture interacts with these three modes

The default trust posture — version-controlled directories starting in Auto, non-version-controlled ones starting read-only until trusted — is a separate mechanism layered on top of the three modes themselves, not a fourth mode. It determines which of the three modes a fresh session effectively starts in in the absence of an explicit flag, which is worth understanding as the reason a brand-new scratch directory behaves differently from an established, version-controlled project even when you didn't pass any sandbox flag to either.

A worked comparison of the three, side by side

Picture the same task — fixing a bug in a small utility function — attempted under each mode. Under read-only, Codex can locate the bug and describe the fix, but can't apply it; you'd copy the suggested change in by hand. Under workspace-write, Codex applies the fix directly, runs the relevant tests, and iterates if they fail — the mode most people mean when they picture "Codex actually fixing something." Under danger-full-access, the same fix happens the same way, but the boundary that would have stopped an accidental edit outside the project entirely isn't there — for this specific task, that boundary was never going to matter, which is exactly the kind of case where reaching for the most permissive mode buys nothing over workspace-write while accepting more risk than the task needed.

Why understanding all three beats memorizing one default

Relying purely on whatever mode the CLI happens to start with by default means never actually deciding — the default is a reasonable general-purpose choice, not a verdict on what every task needs. Understanding what each of the three modes actually restricts is what lets you recognize the specific moments a task calls for something narrower or, more rarely, something broader than the default, rather than running every session under one mode by habit regardless of what it's actually doing.