1.4 Sandbox & Approval Modes

Codex can edit files, run shell commands, install dependencies, and push to branches. That's real power, and real power without a steering mechanism is how you end up with a horror story instead of a productivity win. OpenAI built two layers of control here — most people only ever learn one, then either feel constantly bottlenecked or eventually get burned.

Sandbox mode controls what Codex is physically allowed to touch, enforced at the OS level — Seatbelt on macOS, Landlock on Linux, not just a polite request the model could ignore. Three levels: read-only (Codex can look around and propose changes but can't touch anything — good for a codebase you don't fully trust it on yet), workspace-write (it can edit files and run commands, but only inside your project folder — the sensible default for most day-to-day work), and danger-full-access (no restrictions at all — reserve this for a disposable container or CI environment, never your actual machine with real credentials sitting around).

Approval policy is the second layer, and it controls how often Codex stops to ask before doing something. on-request means it pauses before anything meaningfully risky. never means it runs end to end without interrupting you — appropriate for a task you've already reviewed the plan for, not for the first time you're trying something. The right combination genuinely depends on the task: tight sandbox and frequent approval on unfamiliar or production-adjacent work, looser settings on a scratch branch you're going to review carefully before merging anyway.

Plan mode deserves a callout on its own, because it's the habit that saves you the most grief. Ask Codex to /plan something instead of just doing it, and it explores your codebase and proposes an approach without touching a single file first. You read that plan the way you'd read a junior engineer's PR description before they've written a line of code — does this approach make sense, is it missing an edge case, is it about to touch something it shouldn't — then approve it and let it execute. "In plan mode, figure out how to add auth to this app" gets you something you can push back on before any code exists, instead of a diff you have to unwind.

For headless or CI use specifically, pair codex exec with explicit --sandbox and --ask-for-approval flags rather than leaving anything ambiguous — the correct pairing is always tight, explicit rules defining exactly what's allowed, never "allow everything and hope."

The actual skill here isn't picking one setting and sticking with it forever. It's switching deliberately: loose sandbox and approval on work you understand well enough to review fast, plan mode plus tight settings on anything unfamiliar, production-adjacent, or hard to undo. People who run one configuration for everything end up in one of two bad places — babysitting every keystroke on work that didn't need it, or letting something risky run unattended because they never switched back to careful mode.