Auto mode is the Codex CLI preset most people run day to day: Codex reads files, edits them and runs commands inside your workspace without asking each time, and stops to ask before it writes outside that boundary or needs the network. Per the official docs, Codex recommends it for version-controlled folders. This page covers what auto mode permits, how it differs from read-only and full access, how to run Codex without prompts ("auto approve"), and the three ways to set it.
What Auto Mode Actually Is
Auto mode is not a single setting. It is a combination of two independent controls:
sandbox_mode = "workspace-write"
approval_policy = "on-request"
Or as flags:
codex --sandbox workspace-write --ask-for-approval on-request
- The sandbox decides which files and network resources a command can reach. It is enforced by the operating system, so a command that exceeds it fails rather than being asked about.
- Approvals decide when Codex pauses to ask you before acting.
The codex sandbox subcommand runs a command under the default sandbox, so you can see the enforcement yourself: expect a write outside the workspace and outbound network access (for example curl https://example.com) to fail, as documented.
The Presets
| Preset | Flags | Codex can | Codex asks before |
|---|---|---|---|
| Read-only | --sandbox read-only --ask-for-approval on-request | Read files, answer questions | Any modification |
| Auto | --sandbox workspace-write --ask-for-approval on-request | Read, edit and run commands in the workspace | Writing outside the workspace, network access |
| Auto-review | Auto, plus -c approvals_reviewer=auto_review | Same as Auto | A reviewer handles eligible prompts instead of you |
| Dangerous full access | --dangerously-bypass-approvals-and-sandbox (alias --yolo) | Everything | Nothing |
Allowed values, if you want to combine them differently:
sandbox_mode:"read-only","workspace-write","danger-full-access"approval_policy:"on-request","never", or agranulartable that lets you auto-reject some prompt categories while keeping others interactive
approval_policy = "untrusted" is retired. Older guides (including earlier versions of this one) list it as a valid value. The current Codex documentation says it is no longer supported and can stop the client from starting. The current CLI help lists only on-request and never for --ask-for-approval. If your config.toml still says untrusted, change it to on-request.
Which preset you land in at first launch depends on the folder: Codex recommends Auto for version-controlled folders and read-only for other folders, and it may start read-only until you trust the directory.
Read-only
codex --sandbox read-only --ask-for-approval on-request
Codex reads and answers but changes nothing. Right for reviewing a pull request or exploring a repository you have just cloned. For CI jobs that must never prompt, the docs pair it with --ask-for-approval never.
Auto
codex --sandbox workspace-write --ask-for-approval on-request
Codex edits files and runs commands inside the workspace without interruption. The workspace is the current directory plus temporary directories such as /tmp; /status lists them. Network access is off by default under workspace-write, so an npm install, pip install, git push or curl surfaces as an approval prompt. If you approve the same fetch repeatedly, enable network access deliberately (see below) instead of dropping to full access.
Auto-review
codex --sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review
approvals_reviewer accepts "user" (the default) or "auto_review". With auto_review, only actions that already need approval are reviewed, and by something other than you. It does not change the sandbox. The CLI also has an --approve-for-me flag, which its help describes as routing approval requests through automatic review using the workspace-write sandbox. Treat it as relief from prompt fatigue, not a substitute for the sandbox.
Full access
codex --dangerously-bypass-approvals-and-sandbox
# alias: --yolo
No sandbox, no approvals. The CLI's own help says it is intended solely for environments that are externally sandboxed. Use it in a disposable container or throwaway VM, not on a laptop holding SSH keys and cloud credentials.
"Codex Auto Approve": Skip the Prompts Without Skipping the Sandbox
People searching for codex auto approve usually want Codex to stop asking. There are several ways to get that, with very different risk:
| Goal | Setting | Sandbox still active? |
|---|---|---|
| Stop prompts for in-workspace work (already the Auto default) | workspace-write + on-request | Yes |
| Never prompt; failures go straight back to the model | --sandbox workspace-write --ask-for-approval never | Yes |
| Let a reviewer answer prompts for you | approvals_reviewer = "auto_review" | Yes |
| Remove every control | --yolo | No |
--ask-for-approval never is the safe way to get unattended behaviour: Codex never asks, and a command that needs more than the sandbox allows simply fails and the error is returned to the model. That suits codex exec in scripts. --yolo is the only option that removes the sandbox itself.
The Honest Tradeoff in Auto Mode
What the sandbox protects you from: commands that read or write outside your workspace. Your home directory, system files and other repositories are out of reach without approval.
What it does not protect you from: a destructive command inside the workspace. rm -rf on your own working tree, a migration run against a database whose connection string is in your local .env, or a hard reset are all within the boundary by design. The sandbox limits blast radius; it does not check correctness.
Per the docs, some paths inside a writable root stay read-only: .git (as a directory or pointer file), and .codex, .agents and .aws when they exist as directories. That limits tampering with repository metadata and Codex's own config, but it does not stop edits to your source files, so the practical mitigation is still version control: commit before handing over a large task and use /diff to review.
Approvals only help if you read them. If you approve every prompt reflexively, either the mode or the task is wrong.
Three Ways to Set the Mode
1. Per session, with flags
# Auto
codex --sandbox workspace-write --ask-for-approval on-request
# Read only
codex --sandbox read-only
# Short forms
codex -s workspace-write -a on-request
Flags beat configuration files, so they are the reliable way to force a mode for one run. codex exec --sandbox workspace-write does the same for non-interactive runs.
2. As a default, in config.toml
In ~/.codex/config.toml:
sandbox_mode = "workspace-write"
approval_policy = "on-request"
Or per project, in <project>/.codex/config.toml, for example to hold a sensitive repository to read-only:
sandbox_mode = "read-only"
Project config only loads for trusted projects, so a repository cannot grant itself broader permissions by shipping a config file. See where Codex stores config.toml for precedence.
3. Mid-session, with /permissions
/permissions
Switches approval and sandbox settings inside a running session, so you can start read-only while you agree a plan, then move to Auto without losing context. It is also how to check what is currently in effect.
To write the file instead of remembering flags, the generator below builds a config.toml from your choices:
Codex CLI Config Generator
Generate config.toml and AGENTS.md for OpenAI’s Codex CLI — model, reasoning effort, approval policy, sandbox mode, and MCP servers. Optional private in-browser AI for the context file.
Open the full Codex CLI Config Generator tool →Widening the Sandbox Deliberately
When a tool genuinely needs more than the workspace, widen one thing rather than removing the boundary. Under [sandbox_workspace_write]:
[sandbox_workspace_write]
writable_roots = ["/Users/you/.pyenv/shims"]
# Leave network off unless the tool genuinely needs it
network_access = false
The keys in this table are writable_roots, network_access, exclude_slash_tmp and exclude_tmpdir_env_var. Only network_access appears on the approvals page, so check the others against the Codex configuration reference for your version. Adding one directory to writable_roots is a far smaller concession than danger-full-access, and you fix the cause once instead of approving the same prompt every session. At launch, --add-dir <DIR> adds a directory that is writable alongside the workspace (the CLI help describes it as "additional directories that should be writable").
Named permission profiles
Newer Codex versions also support named permission profiles: default_permissions selects one, and a custom profile is a [permissions.<name>] table that can use extends = ":workspace". The built-in profile names and the rules for combining profiles with sandbox_mode vary by version, so check the Codex configuration reference before mixing the two styles.
What Enforces the Sandbox
- macOS: Seatbelt (
sandbox-exec) with a profile matching the sandbox mode. - Linux:
bwrap(bubblewrap) plusseccomp. - WSL2: uses the Linux sandbox. WSL1 stopped being supported in Codex 0.115.
- Windows: the docs now prefer the MXC sandbox (
[features] prefer_mxc = true), withelevatedandunelevatedmodes described as legacy fallbacks.
If sandboxing cannot initialise on Linux, install bubblewrap through your package manager before reaching for a bypass flag.
Choosing a Mode
| Situation | Suggested mode |
|---|---|
| Reviewing code, exploring an unfamiliar repository | Read-only |
| Day-to-day development in a repository under version control | Auto |
| Unattended script or CI job | workspace-write or read-only with --ask-for-approval never |
| Repository with production credentials in local env files | Read-only, pinned in the project config |
| Disposable container or throwaway VM | Full access, if the speed is worth it |
| Any machine holding credentials you cannot rotate cheaply | Never full access |
Troubleshooting
Codex will not start after I edited config.toml. Check for approval_policy = "untrusted". It is retired; use on-request.
The mode is not what I set. Flags and -c overrides beat config files, and a project config beats your user config. Check for a shell alias carrying --sandbox, then the project's .codex/config.toml. Run /permissions to see what is active.
My project config is ignored. The project is not trusted, and Codex skips the project .codex/ layer for untrusted projects.
Commands needing the network keep prompting. That is network_access = false working as designed. Set it to true under [sandbox_workspace_write] for projects where installs are routine.
A tool fails writing outside the workspace. Add its directory to writable_roots rather than switching to full access.
I cannot edit .git, .codex or .aws inside the workspace. Those are protected paths by design.
Next Steps
- Find and edit the file these settings live in: codex config.toml location, keys and precedence
- Extend Codex with tooling: How to Set Up MCP Servers
- Use read-only mode well: How to Use Codex for Code Review
- Compare with the other CLIs: AI coding CLI sandbox and approval modes compared
- Read the official Codex approvals and security documentation