Set Codex's Leash Before It Runs
You wouldn't hand a new hire your laptop password on day one. Don't do it to your AI coding agent either. OpenAI Codex has two independent settings that decide how much rope it gets: sandbox mode, which controls what it's physically allowed to touch, and approval policy, which controls when it has to stop and ask you first.
Two dials, not one
It's tempting to treat Codex's safety settings as a single trust slider. They're not. Sandbox mode is the hard boundary — enforced at the OS level, not by the model's judgment. Approval policy is the conversational layer — when Codex pauses mid-run to ask permission instead of just acting. You can have a wide sandbox with strict approvals (it could do a lot, but asks constantly), or a narrow sandbox with loose approvals (it rarely asks, but there's little it can do wrong). Knowing which dial controls which failure mode is the whole trick.
The three sandbox modes
| Mode | Read | Write | Network / outside project |
|---|---|---|---|
read-only | Anywhere | Nowhere | No |
workspace-write (default) | Anywhere | Only inside project folder | Asks first |
danger-full-access | Anywhere | Anywhere | Yes, unrestricted |
workspace-write is the default and the one worth understanding. It can read any file on your system — useful for pulling in context from sibling repos or docs elsewhere on disk — but it can only write inside the current project folder. If it needs the network or a path outside that folder, it stops and asks, regardless of approval policy, because that's a sandbox-level restriction. danger-full-access removes the fence entirely; reserve it for a disposable container or CI sandbox, never your primary machine.
The three approval policies
- untrusted — asks before nearly everything. Good for a codebase you don't know or trust yet.
- on-request — asks only when it's about to do something the sandbox wouldn't otherwise allow on its own (leave the folder, hit the network). The balanced default.
- never — never asks; does whatever the sandbox permits. Reserved for automation and CI where no human is present to answer a prompt.
The safe default: workspace-write + on-request
Put the two dials together: sandbox = workspace-write, approval = on-request. Codex reads your whole disk for context, freely edits and creates files inside your project, runs local commands and tests — and stops to ask before doing anything that reaches beyond the project folder or touches the network. That covers the majority of day-to-day feature work without a permission dialog every few seconds.
Save danger-full-access for environments you can throw away: an ephemeral CI runner, a scratch VM, a container rebuilt on every run.
How to set it
Both settings live in Codex's config.toml, so you set them once instead of re-choosing at the start of every session. Set your preferences there and every new session inherits them automatically — no repeated setup, no forgetting to re-tighten a permissive setting you turned on for one risky task.
Picking modes by situation
- New or untrusted codebase:
read-only+untrusted. Let Codex explore and propose before it can touch anything. - Routine feature work in a repo you know:
workspace-write+on-request— the balanced default. - Automated pipelines, throwaway containers, CI:
danger-full-access+never, since there's no human present and the environment is disposable.
Pitfalls
- Treating sandbox mode as the whole story. A wide sandbox with
neverapprovals means Codex genuinely won't ask before doing anything the sandbox allows. - Loosening to full access "just for this one task" and forgetting to revert — it's a config file, not a forced per-session choice.
- Assuming workspace-write is fully safe. It still reads anything on disk, which matters if your project sits next to directories with secrets.
Resources
Building an AI feature? Yeda AI designs, audits, and ships production LLM systems.