Codex CLI --full-auto: what it really does, why it's deprecated, and what I use instead

🔍 What --full-auto really does: two dials in a single flag

Codex CLI has two independent controls: the approval policy (when the agent stops to ask my permission) and the sandbox (what the commands it generates can touch). --full-auto is a shortcut that sets both: approvals off and the sandbox in workspace-write mode, meaning writes are allowed only inside the current repository and temporary folders.

The surprising detail is precedence: if I write codex exec --full-auto --sandbox read-only, the read-only part is simply ignored. The flag forces workspace-write, full stop. It's documented behavior, but counterintuitive: I would expect the more specific flag to win, yet the shortcut does.

That's why I now always think in terms of separate dials: -a (or --ask-for-approval) for approvals, -s (or --sandbox) for the boundary. Two explicit flags say exactly what they do; a shortcut that silently overrides another flag is the kind of surprise I prefer to keep out of my scripts.

# legacy shortcut (deprecated on codex exec)
codex exec --full-auto "update dependencies and run the tests"

# explicit equivalent: approvals + sandbox declared
codex exec -a never -s workspace-write \
  "update dependencies and run the tests"

🧱 The sandbox under the hood: three modes, one boundary per risk level

The Codex sandbox has three modes. read-only: model-generated commands can read files but write nowhere, not even /tmp. workspace-write: writes allowed in the repository and temporary directories, blocked everywhere else. danger-full-access: no filesystem restrictions — the name says it all.

This isn't a software convention but a boundary enforced by the operating system: on macOS Codex uses Seatbelt policies via sandbox-exec, on Linux it builds a Landlock ruleset (with bwrap in recent versions) that restricts the process to the allowed paths. Even in workspace-write, some sensitive paths in the repo stay protected, such as the .git metadata.

Then there's networking: in workspace-write, network access for commands is off by default. If the task needs to download packages I have to enable it myself, with sandbox_workspace_write.network_access = true in config.toml or via -c on the fly. That's why an npm install inside Codex sometimes fails "mysteriously": it's not the npm registry, it's the sandbox doing its job.

⚠️ The deprecation: why --full-auto is disappearing from codex exec

The official documentation is explicit now: for non-interactive runs you use codex exec --sandbox workspace-write, while codex exec --full-auto remains only as a deprecated compatibility path that prints a warning. The direction is clear: explicit, separate flags instead of shortcuts that set multiple things at once.

There's also a historical trap worth knowing. The first Codex CLI (the TypeScript one, spring 2025) had a completely different system: --approval-mode with the values suggest, auto-edit, and full-auto, plus a Docker-based sandbox. The Rust rewrite changed everything — today's policies and sandbox have nothing to do with it — but the web is still full of guides written for the old scheme. If a tutorial mentions suggest/auto-edit or a docker sandbox, I'm reading documentation from the previous era.

The mental replacement I use: --full-auto meant "do everything yourself, but stay in the repo". The modern version of the same sentence is -a never -s workspace-write. Same autonomy, same boundary, but spelled out — and no deprecation warnings in pipeline logs.

🧪 The combinations I actually use, from laptop to CI

Separating the two dials unlocks combinations that didn't exist with --full-auto. For everyday interactive use, the Auto preset (the default: workspace-write with on-request approvals) is the right compromise: the agent works inside the repo and asks my permission only to step outside the boundary or touch the network.

For analysis-only jobs — reports, reviews, questions about the code — I run with -s read-only -a never: the agent reads everything, touches nothing, and never stops to wait for me. That's the configuration I consider the sane default for CI: if the task shouldn't write, the boundary shouldn't let it.

At the opposite end sits --dangerously-bypass-approvals-and-sandbox, alias --yolo: no approvals and no sandbox. It has exactly one legitimate use case — a disposable container or VM acting as the external sandbox — and in that context the official docs themselves suggest danger-full-access so you don't pay for two layers of isolation. On my laptop, with my SSH keys and my files, it never runs.

One last trick: I save recurring combinations as profiles in config.toml and recall them with codex --profile name. And before trusting a boundary I verify it with codex sandbox macos (or linux): it runs any command inside the chosen sandbox and shows me what gets blocked.

• Everyday use: the Auto preset — workspace-write with on-request approvals, no flags to remember.
• In-repo automation: -a never -s workspace-write, the explicit heir of --full-auto, without deprecation warnings.
• Read-only CI: -s read-only -a never for reports and reviews that must not write anything.
• Disposable containers: danger-full-access only when the infrastructure already guarantees isolation.
• Profiles in config.toml: one combination per context, recalled with codex --profile name.

More articles from the blog