Auto mode is the Codex CLI preset most people run day to day: Codex can read files, make edits, and run commands in your workspace without asking each time, but stops to ask before it writes outside that boundary or touches the network. This page covers exactly what auto mode permits, how it differs from the other presets, 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 distinction between the two matters more than the preset name:
- The sandbox decides which files and network resources a command can reach. It is enforced by the operating system, so a command that tries to exceed it fails rather than being asked about.
- Approvals decide when Codex pauses to ask you before acting.
A permissive approval policy with a tight sandbox is still constrained. A loose sandbox with strict approvals relies on you reading every prompt. Auto mode pairs a workspace-limited sandbox with prompts at the boundary, which is why it lands where most people want it.
The Three Presets
| Preset | sandbox_mode | approval_policy | Codex can | Codex asks before |
|---|---|---|---|---|
| Read Only | read-only | on-request | Read files, answer questions | Any modification |
| Auto | workspace-write | on-request | Read, edit and run commands in the workspace | Writing outside the workspace, network access |
| Full Access | danger-full-access | never | Everything | Nothing |
The allowed values, if you want to combine them differently:
sandbox_mode:"read-only","workspace-write","danger-full-access"approval_policy:"untrusted","on-request","never"
Read Only
codex --sandbox read-only --ask-for-approval on-request
Codex reads files and answers questions but changes nothing. This is the right mode for reviewing a pull request, exploring a repository you have just cloned, or asking questions about code you do not want touched. It is also the sensible default when you are still building trust in a new setup.
Auto
codex --sandbox workspace-write --ask-for-approval on-request
Codex edits files and runs commands inside the workspace without interruption. It stops and asks when it needs to write somewhere outside that boundary, or when a command requires network access.
That network behaviour is the part worth internalising: network access is disabled by default under workspace-write. An npm install, a pip install, a git push or a curl surfaces as an approval prompt rather than silently failing or silently succeeding. If you find yourself approving the same fetch repeatedly, that is the signal to enable network access deliberately rather than to drop to full access.
Full Access
codex --dangerously-bypass-approvals-and-sandbox
# alias: --yolo
No sandbox, no approvals. The flag name is doing honest work here. This is appropriate inside a disposable container or a throwaway VM - somewhere losing the entire filesystem would cost you nothing - and inappropriate on a machine holding anything you care about. On a laptop with your SSH keys, cloud credentials and personal files, there is no sandbox boundary left to contain a mistake.
The Honest Tradeoff in Auto Mode
Auto mode grants real autonomy, and it is worth being precise about where the boundary sits.
What the sandbox protects you from: a command that reads or writes outside your workspace. Your home directory, system files, other repositories, and anything else on the machine are out of reach without an explicit approval.
What it does not protect you from: a destructive command inside the workspace. rm -rf against your own working tree, a migration run against a database whose connection string is in your local .env, or a git reset --hard are all inside the boundary by design - that is what "workspace-write" means. The sandbox is a blast-radius limiter, not a correctness check.
The practical mitigation is not a tighter sandbox but version control. Work in a git repository, commit before handing over a large task, and you have a real undo for anything inside the workspace. Use /diff to review changes including untracked files before you commit.
The second real consideration is that approvals only help if you read them. A stream of prompts approved reflexively provides the ceremony of oversight without the substance. If you are clicking through every prompt, either the mode is wrong for the task or the task is wrong for the mode.
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 every configuration file, which makes them the reliable way to force a mode for one run.
2. As a default, in config.toml
Set it in ~/.codex/config.toml:
sandbox_mode = "workspace-write"
approval_policy = "on-request"
Or per project, in <project>/.codex/config.toml - useful for holding a sensitive repository to read-only regardless of your personal default:
sandbox_mode = "read-only"
Project config is only loaded for trusted projects, so a repository cannot grant itself broader permissions simply by shipping a config file. See where Codex stores config.toml for the full precedence order.
3. Mid-session, with /permissions
/permissions
Switches approval and sandbox settings inside a running session, so you can start read-only while you and Codex agree on a plan, then move to auto for the execution without losing context.
Widening the Sandbox Deliberately
When a tool genuinely needs a path outside the workspace, name that path rather than removing the boundary. Under [sandbox_workspace_write]:
[sandbox_workspace_write]
writable_roots = ["/Users/you/.pyenv/shims"]
network_access = false
Verified keys in this table are writable_roots, network_access, exclude_tmpdir_env_var and exclude_slash_tmp.
Adding one directory to writable_roots is a far smaller concession than danger-full-access, and it is durable - you fix the cause once instead of approving the same prompt every session. The same reasoning applies to network_access = true: turning it on for a project that genuinely installs dependencies is a considered decision, where switching to full access to achieve the same thing throws away the file boundary as well.
To grant additional read access during a session, /sandbox-add-read-dir does that without touching write permissions. --add-dir does the equivalent at launch.
What Enforces the Sandbox
- macOS - the built-in Seatbelt framework.
- Linux and WSL2 - bubblewrap (
bwrap), which must be installed and needs kernel support for unprivileged user namespaces. A bundled helper serves as a fallback. - Windows - configured via the
[windows]table, wheresandboxtakes"elevated"or"unelevated"./setup-default-sandboxwalks through the elevated setup.
If sandboxing cannot initialise on Linux, install bubblewrap through your package manager before reaching for a bypass flag - a missing dependency is not a reason to run unsandboxed.
Choosing a Mode
| Situation | Suggested mode |
|---|---|
| Reviewing code, exploring an unfamiliar repository | Read Only |
| Day-to-day development in a git repository | Auto |
| A repository with production credentials in local env files | Read Only, or Auto with a project config pinning it |
| Disposable container or throwaway VM | Full Access, if the speed is worth it |
| Any machine holding credentials you cannot rotate cheaply | Never Full Access |
A reasonable starting configuration for most people:
# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[sandbox_workspace_write]
network_access = false
Then pin individual sensitive projects to read-only in their own .codex/config.toml.
Troubleshooting
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 or wrapper script carrying --sandbox, then check the project's .codex/config.toml.
My project config is being ignored. The project is not trusted. Codex skips the entire 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 dependency installs are routine.
A tool fails writing outside the workspace. Add its directory to writable_roots rather than switching to full access.
I am not sure what is currently in effect. Run /permissions inside the session.
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
- Read the official Codex approvals and security documentation