Codex CLI sandbox, approval modes and yolo mode

Codex does not have one permission switch. It has two, and they do different jobs:

• Sandbox (-s, --sandbox) is enforcement. The operating system stops a command from writing outside the allowed folders or reaching the network, whatever the model intended.
• Approval policy (-a, --ask-for-approval) is conversation. It decides whether Codex asks you before it does something the sandbox would block.

On codex-cli 0.163.0 the values are:

Older guides also mention untrusted and on-failure. The current CLI rejects both on the command line (invalid value 'untrusted' for '--ask-for-approval'). OpenAI's docs call untrusted retired and on-failure deprecated, and warn that a leftover untrusted in config can stop Codex from starting.

The useful combinations:

# Read only: look, change nothing
codex --sandbox read-only --ask-for-approval on-request

# Auto: edit the workspace, ask before going further (the recommended default)
codex --sandbox workspace-write --ask-for-approval on-request

# Full access: no fence, no questions
codex --sandbox danger-full-access --ask-for-approval never

Yes. The long flag is --dangerously-bypass-approvals-and-sandbox, and --yolo is an accepted alias for it. Both skip every confirmation prompt and run commands with no sandbox at all.

codex --yolo
# same as
codex --dangerously-bypass-approvals-and-sandbox

The CLI's own help text describes it as "EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed". Take that literally. With yolo on, a model that misreads a task can delete files outside the repository, push to a remote, read credentials in your home directory or install packages, and nothing stops to ask. It works the same on codex exec, which is where it does the most damage, because nobody is watching.

Use yolo inside a container, a disposable VM or a throwaway cloud box that has no credentials you care about. Do not use it on your daily machine, in a checkout with uncommitted work, or anywhere a cloud CLI is already logged in.

Older versions had --full-auto as a shortcut for the workspace-write sandbox plus on-request approvals. codex-cli 0.163.0 no longer accepts it and stops with error: unexpected argument '--full-auto' found. Spell the pair out instead:

codex --sandbox workspace-write --ask-for-approval on-request

OpenAI's docs call this pair the Auto preset. It is the closest thing Codex has to an auto mode: file edits and ordinary commands inside the project go through without asking, and Codex stops to ask before anything that needs the network or a path outside the workspace.

Letting a reviewer answer instead of you

There is a second kind of auto. --approve-for-me runs with the workspace-write sandbox and sends approval requests to automatic review instead of to you. The config equivalent is approvals_reviewer = "auto_review", which works with approval_policy = "on-request". The default is "user". Auto review only looks at actions that would have asked anyway. It does not widen the sandbox, and the /approve slash command lets you approve one retry of an action it denied.

There are four places, from most temporary to most permanent:

1. Mid-session: type /permissions in the Codex TUI. It sets what Codex can do without asking, for example moving between Auto and Read Only, and applies from then on. There is no /approvals command in the current list. /status shows the active settings.
2. For one run: pass --sandbox and --ask-for-approval, or -c sandbox_mode=read-only. Flags win over config.
3. For a named setup: a profile file (below), selected with -p.
4. As your default: ~/.codex/config.toml.

Codex may also start a folder in read only until you trust it. Trust is stored per path in config, as [projects."/path/to/project"] with a trust_level. OpenAI recommends Auto for folders under version control and read only for folders that are not.

The keys live in $CODEX_HOME/config.toml, which is ~/.codex/config.toml unless you moved it:

approval_policy = "on-request"     # or "never"
sandbox_mode    = "workspace-write" # or "read-only", "danger-full-access"

[sandbox_workspace_write]
network_access = true               # outbound network inside the sandbox
writable_roots = ["/home/me/.cache/pip", "/home/me/shared-lib"]
exclude_slash_tmp = false           # true removes /tmp from the writable set
exclude_tmpdir_env_var = false      # true removes $TMPDIR from the writable set

writable_roots adds folders Codex may edit without dropping the sandbox. For a single run, --add-dir <DIR> does the same thing from the command line. network_access is the switch people go looking for when npm install or pip install fails inside workspace-write.

Two more advanced forms exist. approval_policy also takes a granular table, approval_policy = { granular = { ... } }, with booleans for sandbox_approval, rules, mcp_elicitations, request_permissions and skill_approval, so you can let one kind of prompt through and silence another. Newer configs can also name a permissions profile with default_permissions (built in: :read-only, :workspace, :danger-full-access). Do not combine that with sandbox_mode or [sandbox_workspace_write].

Profiles

In the current CLI a profile is a separate file next to config.toml, named <name>.config.toml, and -p <name> layers it on top of the base config. A locked down profile for reviewing unfamiliar code:

# ~/.codex/review.config.toml
sandbox_mode    = "read-only"
approval_policy = "on-request"

codex -p review

Codex ignores profile and profiles in a project-local .codex/config.toml, so keep profiles in your user config.

The sandbox is enforced by the operating system, not by the model behaving itself. Each platform uses its native mechanism:

• macOS: Seatbelt, the built-in sandbox, applied through sandbox-exec with a Codex profile. Nothing to install.
• Linux and WSL2: bubblewrap (bwrap) plus seccomp. Codex uses the first bwrap on your PATH. Without one it falls back to a bundled helper that needs unprivileged user namespaces, and it prints a startup warning if neither works. Install it with sudo apt install bubblewrap or sudo dnf install bubblewrap. On Ubuntu 24.04 the AppArmor user namespace restriction can block it. OpenAI's fix is sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict.
• Windows: the native Windows sandbox when you run Codex from PowerShell, and the Linux sandbox under WSL2. WSL1 has not been supported since 0.115.

Some paths stay read only even inside a writable root: .git (including a .git pointer file and the Git directory it resolves to), .codex, .agents and .aws. That is why Codex in workspace-write can edit your code but has to ask before it commits.

To check that the sandbox itself works on a machine, without involving the model or spending tokens, run any command through it with codex sandbox:

codex sandbox ls

If that prints a bwrap: error instead of a directory listing, the problem is the machine (bubblewrap missing, or user namespaces blocked), not your Codex settings.

Most "I need to run Codex outside the sandbox" problems need a smaller hole than turning it off. Work down this list and stop at the first step that fixes it:

1. Approve the one command. With on-request, Codex asks before it runs something the sandbox would block. Saying yes runs that command outside the fence. Nothing else changes.
2. Turn on network only. network_access = true under [sandbox_workspace_write] fixes package installs and API calls and keeps the filesystem fence.
3. Add a folder. --add-dir or writable_roots for a cache, a sibling repository or a build output directory.
4. Write a rule. Codex reads execpolicy .rules files that allow, prompt or forbid command prefixes outside the sandbox, for when one specific command keeps asking.
5. Full access in a box you can throw away. --sandbox danger-full-access, or --yolo, inside a container or VM. Here the container is your sandbox.

If your work involves Docker, system package managers or anything that needs root, the honest answer is step 5 in a VM rather than full access on your laptop.

On-request approvals have one practical cost: when Codex asks, the run waits until you are back at that terminal. Termdeck shows the prompt in your browser and on your phone instead, so a run that stopped four minutes in can be answered from wherever you are.

• Each chat has a mode picker. On Codex, Supervised also restricts the sandbox to read only, Auto is workspace-write with on-request, and Full access is no sandbox and no prompts. Accept edits is not offered, because Codex has no such pair.
• The approval card shows the command as Codex will run it, without the shell wrapper, with Codex's own reason above it.
• You can allow one exact command for the rest of the chat, or, when Codex offers a rule worth saving, keep it on that machine so it also applies in your terminal.
• TERMDECK_FULL_ACCESS=off in a machine's ~/.termdeck/agent.env makes that machine refuse Full access entirely.

The details are in Approvals and permissions and Phone and push. For the same question on the other engines, see Claude Code permission modes and Grok CLI permission modes.