Guides / Codex CLI

Codex CLI permissions: approval_policy, sandbox_mode and full-auto bypass

Codex CLI reads config.toml (in ~/.codex/ or a project's .codex/). Two keys control how much it can do without you: approval_policy (when it asks) and sandbox_mode (what it can touch). Profiles can set both too.

Data snapshot: 2026-10-20. Counts are unique public GitHub configs, identical files counted once. Aggregates only; no repos are named.

What the settings in .codex/config.toml do

approval_policy: on-request runs what the sandbox allows and asks before going beyond it; never never asks. Older values like untrusted and on-failure are retired in current Codex releases, so remove them.
sandbox_mode: read-only can only read; workspace-write can write inside the workspace (network off by default); danger-full-access removes the sandbox entirely.
[sandbox_workspace_write]: Fine-tunes workspace-write, e.g. network_access = false and extra writable_roots.
[profiles.<name>]: Named presets that can override both keys. A permissive profile counts even if the top level is safe.

What public Codex CLI configs look like

Unique public configs analyzed	4,194
Configs that set approval_policy or sandbox_mode	1,200
…full bypass (never + danger-full-access)	12.9%
…sandbox_mode = danger-full-access	18%
…approval_policy = never	22.2%
All configs with a credential-looking literal	2.1%
Configs that define MCP servers	55.4%
Leaderboard	#3 of 4 on the safety leaderboard (score 92.9)

See the full dataset and leaderboard methodology. Public repos skew toward demos and templates, so treat these as a lower bound on what is possible, not a census.

Common risky patterns

approval_policy = "never" + sandbox_mode = "danger-full-access"
No prompts and no sandbox: the agent can run anything on your machine with your permissions.
danger-full-access as a default
Use it only inside a disposable container or VM. workspace-write covers most coding work.
Tokens pasted into [mcp_servers.*.env]
Committed config files leak keys. Reference environment variables instead, and rotate any key that was committed.
Permissive profiles
A yolo profile in a shared config is one flag away. Keep it in your personal ~/.codex/config.toml, not the repo.

A safer starting config

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

[mcp_servers.github]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-github"]
env_vars = ["GITHUB_TOKEN"]  # forwarded from your shell, not hardcoded

Adjust the allowed commands to your project. Rotate any key that was ever committed, even if you remove it later.

Grade your config

The web grader reads JSON configs, so it can't parse config.toml yet. Use the checklist above, or grade your Claude Code, Gemini CLI or Cursor configs in the grader. Grading runs in your browser and the config is never stored. You get an A–F grade, the fixes, and a README badge.

Open the grader Grade from your agent (MCP)

Codex CLI permissions FAQ

What does the Auto preset (--full-auto) do in Codex?

The Auto preset runs with sandbox_mode workspace-write and approval_policy on-request: Codex edits and runs commands inside the workspace and asks before writing outside it or using the network. The network is off by default in workspace-write.

What is Codex --yolo?

--yolo is an alias for --dangerously-bypass-approvals-and-sandbox: no sandbox and no approval prompts. OpenAI's docs label it elevated risk and not recommended outside an isolated container.

How common is full bypass in public Codex configs?

12.9% of 1,200 unique public configs that set approval_policy or sandbox_mode combine approval_policy = "never" with sandbox_mode = "danger-full-access".

Can I grade a Codex config.toml?

Not in the web grader yet; it reads JSON. Use the checklist on this page.