Suggest, auto-edit, full-auto: choosing Codex's leash
Every coding agent has a leash setting; Codex is just unusually explicit about it. Three approval modes (suggest, auto-edit, full-auto) decide what the agent may do without asking you first. Most people treat the choice as a speed preference, but it's a risk decision, and the currency it trades in is reversibility.
What each mode actually permits
| Mode | File edits | Commands | What you are actually risking |
|---|---|---|---|
| Suggest | Approved one by one | Approved one by one | Your attention span |
| Auto-edit | Automatic | Approved one by one | Unreviewed diffs piling up |
| Full-auto | Automatic | Automatic, inside a sandbox | Whatever the sandbox does not cover |
Suggest is the glass box: Codex reads the repo freely, but every patch and every command stops for sign-off. Auto-edit lets it write files without asking while still gating commands. Full-auto lets it do both, and this is where the design earns some respect: full-auto is not raw shell access. Codex runs the work inside a sandbox, with writes confined to the workspace and network access disabled by default, so a bad turn cannot exfiltrate secrets or pull surprises off the internet mid-task. That containment is the only reason full-auto is a defensible setting at all; I unpack what the sandbox actually enforces separately, and the general argument in sandboxing coding agents.
Notice the asymmetry the table encodes: edits loosen before commands do. That is the whole point. File edits in a git repo are nearly risk-free: git checkout undoes anything the agent writes. Commands are where irreversibility lives: the migration against a shared database, the deploy, the package publish. Codex keeps commands gated the longest because that is where the real damage is.
Match the mode to reversibility, not confidence
The wrong question is how much you trust the model. Confidence drifts up with every good session and collapses in one bad afternoon; it is a terrible control input. The stable question is what the undo costs if the agent's next action goes wrong. A throwaway spike in a scratch repo calls for full-auto, obviously; the worst case is deleting the directory. A well-tested service where CI catches regressions earns the speed of auto-edit, because the test suite is the real leash. Anything touching auth, billing, migrations, or infrastructure stays in suggest mode, indefinitely, no matter how good the models get.
The mode question is never how good the model is. It is how cheaply you can undo the thing it does when it is wrong.
Autonomy is earned per repo
The discipline that makes this sustainable: autonomy is a property of the repo, not of your global config. Every new codebase starts in suggest mode, whatever your habits elsewhere. You do not yet know where this repo keeps its sharp edges. After a stretch of clean sessions, with diffs you would have written yourself, promote one notch. After one genuinely bad call, demote and let the trust rebuild. Setting full-auto globally because it went well in one tidy side project is how people end up with war stories.
Suggest mode has a failure mode of its own, and it deserves naming: approval fatigue. Fifty prompts a session and your review decays into reflexive approval, which is worse than honest automation because it still feels like oversight. If you catch yourself approving without reading, either fence the task tighter or promote the mode deliberately: good human-in-the-loop design makes each approval mean something, rather than maximizing how many there are.
So: suggest for anything new or irreversible, auto-edit for tested codebases where CI is the actual reviewer, full-auto for sandboxed and disposable work. Write the choice down per repo and revisit it when the stakes change, treating every promotion as a decision you could defend in an incident review. The leash exists because you cannot un-run a command, not because the model is bad.