The direct answer
Codex full auto today: two very different things
Two different ideas hide behind the phrase Codex full auto. The current CLI reference documents codex exec --full-auto as a deprecated compatibility flag. Where supported, it selects the workspace-write sandbox, while codex exec itself uses the never approval policy for headless runs. The documented replacement is codex exec --sandbox workspace-write. The full bypass is a different flag: --dangerously-bypass-approvals-and-sandbox, with --yolo as its alias, removes both approval prompts and the Codex sandbox.
Conflating those two is how machines get hurt. This guide separates the three controls Codex actually exposes, gives you a command matrix from safest to most permissive, and shows how to stop the approval prompts without also removing the walls.
Last verified against the official Codex CLI reference on September 5, 2026. Flags move between releases; codex --help on your installed version and the official reference together are the source of truth.
The core model
The three controls: approvals, sandbox, and network
Every Codex autonomy question resolves into a combination of three independent settings:
- Approvals:
--ask-for-approvaldecides when Codex pauses for a human. Current CLI values areuntrusted,on-request, andnever;on-failureis deprecated. This controls interruptions, not the sandbox boundary. - Sandbox:
--sandboxsets the baseline for model-generated commands:read-only,workspace-write, ordanger-full-access. With an interactive approval policy Codex may ask to go beyond that baseline; withnever, the request is rejected. - Network:
workspace-writeblocks outbound command network access by default. Enable it explicitly withsandbox_workspace_write.network_access = truein configuration, and treat network as a third decision.
Naming the combination you want is the difference between reducing prompts and removing the walls. The matrix below is those combinations, ordered by how much they trust the run.
Not the same flag
Codex full auto vs --yolo
codex exec --full-auto uses the workspace-write sandbox, and codex exec uses never approvals. Commands that need to leave that boundary are rejected rather than surfaced as approval requests.
--yolo, the alias of --dangerously-bypass-approvals-and-sandbox, removes Codex approvals and the Codex sandbox at once. Commands then run with the permissions available to the Codex process, although an external container or VM can still constrain them. This is a different risk class, and it belongs only inside a disposable, isolated environment that you would be comfortable throwing away.
Pick a row
The safer command matrix
Four combinations cover almost every real use:
| Goal | Command | Files | Network | Human involvement |
|---|---|---|---|---|
| Read-only unattended analysis | codex exec --sandbox read-only "<task>" | Read only | Off | None |
| Supervised working session | codex --sandbox workspace-write --ask-for-approval on-request | Workspace | Off by default | On request |
| Unattended workspace run | codex exec --sandbox workspace-write "<task>" | Workspace | Off by default | None |
| Full bypass, isolation required | codex exec --yolo "<task>" | Not restricted by Codex | Not restricted by Codex | None |
The third row is what most people asking how to stop Codex approval prompts actually want: no interruptions, walls intact. The fourth row is legitimate only when an external boundary, a container or VM built for the failure case, takes over the job the sandbox was doing.
Off the deprecated flag
How to migrate from --full-auto
Wherever scripts, shell aliases, or CI jobs still say codex exec --full-auto, use the documented replacement codex exec --sandbox workspace-write "<task>". codex exec already uses the never approval policy, so there is no approval flag to add after the exec subcommand. Explicit flags survive documentation changes better than compatibility aliases, and they read as a decision instead of a habit.
If you use configuration profiles, encode the combination once in config.toml and select the profile per run. Whichever route you take, verify against codex --help on the version you actually have installed; deprecated aliases are exactly the flags most likely to shift behavior between releases.
The middle path
Run Codex without prompts and keep the sandbox
For an unattended run, use codex exec --sandbox workspace-write "<task>". codex exec uses never approvals, writes remain limited to configured writable roots, and outbound command network stays off unless sandbox_workspace_write.network_access is enabled.
The important property: if a command needs permission beyond the sandbox, it fails and returns control to the model; in never mode it is not escalated to the user. The sandbox is still the wall; you have only turned off the doorbell.
The last resort
When full bypass is appropriate
--dangerously-bypass-approvals-and-sandbox has one legitimate home: an environment that assumes the agent may do the wrong thing and is built to absorb it. Before using it, check every line:
- A disposable container or VM, one run per environment, non-root user.
- Only the repository mounted. No home directory, no credential stores, no Docker socket.
- No production credentials inside the environment; scoped short-lived tokens only if unavoidable.
- Outbound network disabled or restricted to an explicit allowlist.
- Work lands on a temporary branch, and the diff gets reviewed before merge.
- A wall-clock timeout on the job, enforced outside the agent.
The reasoning behind each line is covered in AI agent sandboxing: when the built-in walls come down, the environment is what remains.
Not working?
Why Codex still asks for approval
If prompts keep appearing after you thought you turned them off, work down this list:
- With
on-request, a command that needs network access or permission beyond the sandbox can create a sandbox approval request. Withnever, that request is rejected instead of shown to the user. - Command-line flags and
--configoverrides take precedence over project, profile, and user configuration. Managed requirements or wrappers can still constrain effective permissions. - MCP tools and integrations can carry their own approval requirements, separate from the sandbox setting.
- You are running through an IDE surface or wrapper that applies its own policy on top of the CLI.
- The deprecated
--full-autoalias behaves differently across versions; replace it with explicit flags before debugging anything else. - Version drift: compare
codex --versionand the official CLI reference before assuming a bug.
Choose deliberately
Which mode should you use?
Map the need to the matrix instead of reaching for the biggest flag:
- Analyzing unfamiliar code: read-only sandbox, never ask. Nothing can be written, so nothing needs approving.
- Working alongside the agent: workspace-write with on-request approvals keeps you in the loop exactly where it matters.
- Unattended but accountable: workspace-write with never ask. Prompts gone, walls standing. This is the default answer.
- Full bypass: only with the isolation checklist above satisfied, and only for runs you could throw away.
One layer up
The same three controls, handled at the infrastructure layer
HarnessRouter is the world's first unified interface for agent harnesses. A unified interface means one API contract for running complete agent harnesses: starting tasks, streaming progress, continuing sessions, and collecting files and results work the same way across every harness on the platform.
Codex is one of the harnesses that runs there, server-side, each run inside its own isolated per-run sandbox, so approvals versus walls stops being a per-machine flag decision. One honest limit: a sandbox still reaches whatever you explicitly grant it, including mounted data, injected credentials, and permitted network targets. Isolation bounds the blast radius; it does not remove the need to grant carefully.
FAQ
Codex full auto FAQ
Is Codex --full-auto the same as --yolo?
No. In non-interactive mode, codex exec --full-auto is a deprecated compatibility path for the workspace-write sandbox, while codex exec uses never approvals. --yolo removes both Codex approvals and the Codex sandbox.
Is codex exec --full-auto deprecated?
Yes. The current CLI reference calls it a deprecated compatibility flag and says to prefer --sandbox workspace-write. Use codex exec --sandbox workspace-write "<task>"; codex exec already uses never approvals.
How do I stop Codex asking for approval without disabling the sandbox?
For an interactive session, use codex --sandbox workspace-write --ask-for-approval never. For scripts, use codex exec --sandbox workspace-write "<task>"; codex exec already uses never. Requests outside the sandbox are rejected instead of escalated.
Does workspace-write allow internet access?
Not by default. Enable outbound command network access explicitly with sandbox_workspace_write.network_access = true; web search, apps, and MCP traffic have separate controls.
When should I use --dangerously-bypass-approvals-and-sandbox?
Only inside a disposable, isolated runner such as a locked-down container or VM, with no production credentials, restricted network, and a reviewed diff before anything merges. Outside that setup, use workspace-write with never ask instead.
Run Codex with containment built in
Start a task through one API and let every run execute server-side in its own isolated sandbox, with sessions, streaming, and artifacts handled for you.
Run your first agent free