The three sandbox levels - read-only, workspace-write, danger-full-access

Codex splits trust into two independent dials: the approval policy (-a) decides when work stops to ask you, and the sandbox (-s) decides how far the agent can reach in the first place. This lesson is about the second dial - the wall. It is enforced by the execution environment rather than the agent’s judgment. An approval prompt is a request the agent makes; the sandbox is the default boundary the request may need to cross. When the code in front of the agent holds something you care about - financial records, credentials, a production config - you combine a tight sandbox with an approval policy that matches whether escalation is acceptable.

Worth seeing why that wall holds, because “enforced by the operating system” is doing real work in that sentence. On macOS the sandbox is Seatbelt - the same sandbox-exec mechanism that confines system apps - applied to the agent’s process tree. On Linux, Codex uses bubblewrap (bwrap) plus a seccomp filter: bwrap deploys the kernel’s namespace primitives, the ones containers are built on, and seccomp restricts the syscalls available inside. Windows runs its own native sandbox; under WSL2, Codex uses the Linux stack. (These mechanisms are as named in the agent approvals and security docs, checked October 2026.)

In every case the enforcement lives in the kernel or the OS policy layer, not in Codex’s own code. That’s what makes it a real boundary: a process-level check can be reasoned around by a bug or an exploit in the process itself, but an OS-level policy is enforced on the process from outside it. For an operation running under the configured sandbox, the agent can’t disable the policy, can’t forget it, can’t talk its way past - the disallowed syscall simply fails. (An approval you grant can move an operation to a different execution context, as the read-only section notes; that is the gate opening, not the wall moving.) That is a categorically stronger guarantee than any instruction you could write in AGENTS.md.

One caveat for other platforms: before you trust the wall anywhere, check which OS primitive is doing the enforcing there. The guarantee is only as strong as that answer.

There are three levels. Walk up them from tightest to loosest.

read-only - it can look, it cannot change

codex -s read-only

The agent can read files and reason about them. It cannot edit, and it cannot run commands that need to write: under on-request - the approval policy that pauses when an action hits the boundary - those actions stop and ask; under never - the policy that never pauses - they are refused outright. Read-only plus never is reads only - no escalation path at all, which is exactly what a non-mutating unattended audit wants. With interactive approvals, read-only is a cautious default, not a promise that no write can ever be authorized.

This is the right level whenever you want analysis without consequences: “audit this money path and tell me everywhere a float touches a cents value” - you want the findings, not a byte changed while it looks. It’s also the safest way to point Codex at unfamiliar code for the first time. Nothing to write means the approval axis is free to move: even never, with no checkpoints anywhere, has no harmful write to let through here.

workspace-write - it can edit the project, but not escape it

codex -s workspace-write

This is the level you’ll use for most hands-on work. The agent can read and write inside the workspace by default and run routine local commands there; requests to step outside the boundary or use the network stop for approval when the policy allows escalation. Outbound network is off by default here too. Writing inside the project does not imply reaching the internet.

Be precise about what “inside the workspace” means, because the default fence is slightly wider than the project. The writable workspace is the working directory plus the system’s temporary directories - /tmp and $TMPDIR - with .git protected read-only inside it: the agent can rewrite your working tree, but operations that write Git’s own state (commits, branch changes) write .git and are therefore boundary crossings like any other write outside the permitted set. The config keys exclude_slash_tmp and exclude_tmpdir_env_var exist to remove the temp directories from the fence; both default to leaving them writable. /status lists which directories the workspace actually covers - worth a look before you reason about the fence from memory.

For a job that reads a handful of project files, edits two of them, and runs an offline test suite whose writes stay in permitted locations, this is the right fence when you are present to review escalation requests: every action lands inside the fence. A suite is not automatically offline - tests that fetch fixtures over the network or rewrite Git state cross the boundary and stop (or fail) like any other crossing. The wall isn’t what decides whether any of them stops for a y/n; that call belongs to the approval axis. workspace-write decides where the edits may land, never how many of them land without asking first.

Two boundaries of workspace-write are configurable, and the network and directories lesson covers both: which directories beyond the workspace count as writable (writable_roots and --add-dir), and whether network is allowed (network_access). Out of the box neither is widened - writes stay in workspace plus temp, and the network stays off.

danger-full-access - no fence at all

codex -s danger-full-access

The name is the documentation. There is no sandbox: the agent can read and write anywhere on the filesystem your user account can, and the network is wide open. Nothing is enforced, so nothing protects you but the agent’s behavior and whatever the approval dial is set to.

There are legitimate uses - a throwaway container, a CI runner that’s already isolated, a genuinely-needs-the-whole-machine operation you’re supervising closely. But on your actual laptop, with real records in scope, this is the wrong answer almost by definition. When you think you need it, the right move is usually to narrow the ask - add the one directory or capability the agent needs rather than unlocking the whole machine. If the fence is in your way, cut a door - don’t take the fence down.

The wall vs. the checkpoint

Hold the distinction one more time, because it’s the mental model the rest of the chapter rests on. The sandbox is a property of the environment and defines the default boundary. The approval policy is a property of the workflow and decides whether a blocked or exceptional action pauses, is reviewed, or is refused. Together they are control in the concrete sense this course keeps returning to: an enforced boundary plus an intervention point, rather than guidance the agent could weigh or skip. For hard non-mutation, combine read-only with never; for interactive work, a read-only sandbox can still present an approval path. The per-platform enforcement details are in the agent approvals and security docs.

You’ve got the wall picked. Now choose the checkpoint: the approval policies, and which fits your work.