# Codex CLI approval modes and sandbox, explained

> Codex CLI approval modes are two settings: the sandbox and the approval policy. Auto pairs workspace-write with on-request; untrusted is retired.

Source: https://shuriken.sh/guides/codex-cli-approval-modes

Codex CLI approval modes are two settings: the sandbox and the approval policy. Auto pairs workspace-write with on-request; untrusted is retired.

By Shuriken Updated 27 October 2026 5 min read

**Contents**

Codex CLI approval modes are set by two keys in config.toml, or two flags. sandbox_mode (--sandbox) decides what Codex can touch: read-only, workspace-write or danger-full-access. approval_policy (--ask-for-approval, -a) decides when it asks: on-request or never. In a git repository Codex recommends Auto, which is workspace-write with on-request.

We checked every flag, key and example here against OpenAI's [approvals and security page](https://learn.chatgpt.com/docs/agent-approvals-security) on 23 October 2026, and again on 25 October 2026.

## What Codex picks when you start it #

A git repository gets Auto as the recommendation; a folder without version control gets read-only. Some setups also hold Codex in read-only until you trust the folder, at the onboarding prompt or later with /permissions.

## The sandbox: what Codex may touch #

| sandbox_mode | What Codex can do |
| --- | --- |
| read-only | Read files and run commands that only read |
| workspace-write | Read, edit and run commands inside the working folder. Asks to edit outside it, or to run a command that needs the network |
| danger-full-access | Read, edit and run anything, with network access, without asking |

Even in workspace-write, four paths in the project stay read-only, with everything under them:

- .git, as a folder or a file. When it is a gitdir: pointer file, the Git folder it points to is protected too.
- .agents, if it is a folder.
- .codex, if it is a folder. Codex can't rewrite its own project config.
- .aws, if it is a folder.

None of this relies on the model behaving, because the operating system enforces it. macOS runs each command through sandbox-exec with a Seatbelt profile (-p) for the mode; Linux uses bwrap plus seccomp; Windows uses MXC, with elevated and unelevated kept as legacy fallbacks. Under WSL2 Codex uses the Linux sandbox, and WSL1 stopped working in version 0.115, when that sandbox moved to bwrap. The Windows modes and what to do when their setup fails are in [Codex CLI on Windows](https://shuriken.sh/guides/codex-cli-on-windows).

To see what a mode blocks before Codex runs into it, put a command of your own through codex sandbox:

bash
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

Docker is the exception. Inside a container the Linux sandbox may fail if the container blocks namespaces, setuid bwrap or seccomp, and OpenAI's answer is to make the container the boundary and run Codex in it with --sandbox danger-full-access.

## The approval policy: when Codex asks #

| approval_policy | Behaviour |
| --- | --- |
| on-request | Commands the sandbox allows run without asking; anything beyond it asks |
| never | Never asks. What the sandbox forbids fails |
| { granular = { ... } } | Keeps some kinds of approval interactive and rejects others automatically |
| untrusted | Retired. OpenAI says it can stop Codex from starting; remove it |

never is not the same as full access. Paired with workspace-write, Codex still can't write outside the project; a command that tries just fails, because nobody is asked.

OpenAI's example of the granular form has one key per prompt type it covers: sandbox approvals, execpolicy rules, MCP elicitations, request_permissions and skill scripts.

toml
approval_policy = { granular = {
sandbox_approval = true,
rules = true,
mcp_elicitations = true,
request_permissions = false,
skill_approval = false
} }

The page doesn't say in words what true and false do. We'd test the split on a scratch repository before relying on it.

### Moving off untrusted #

The untrusted row needs action, since Codex can refuse to start with it. For "ask before every command" in one repository, OpenAI's replacement is a trust level in your user config, with the approval_policy line deleted:

toml
[projects."/path/to/project"]
trust_level = "untrusted"

Commands there then need approval unless an execution-policy rule allows them. For read-only work with prompts, run codex --sandbox read-only --ask-for-approval on-request instead.

## The flags #

| Flag | Effect |
| --- | --- |
| --sandbox <mode> | Sandbox for this run |
| --ask-for-approval <policy> , -a | Approval policy for this run; -a never turns prompts off |
| --dangerously-bypass-approvals-and-sandbox , --yolo | No sandbox, no approvals (OpenAI: not recommended); web search goes live instead of cached |
| -c approvals_reviewer=auto_review | Sends eligible approval requests to Auto-review instead of you |
| codex exec --sandbox workspace-write | OpenAI's line for non-interactive runs |

The pairs OpenAI's table names:

| Setup | Flags |
| --- | --- |
| Auto | none, or --sandbox workspace-write --ask-for-approval on-request |
| Read-only with prompts | --sandbox read-only --ask-for-approval on-request |
| Read-only CI | --sandbox read-only --ask-for-approval never |
| Full access | --yolo |

OpenAI's page ships two profile files, one at each end. The same lines in [config.toml](https://shuriken.sh/guides/codex-cli-config-toml) make a permanent default:

toml
# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode = "read-only"

codex --profile readonly_quiet starts with the second. Inside a session, /permissions switches mode, and /status prints the folders Codex treats as the workspace.

Shuriken runs Claude Code, Codex, Gemini CLI and 64 more agents side by side, with your own sign-ins.

[Download](https://shuriken.sh/download)

## Turning on network access #

Network access is off in workspace-write until you add this. It's the setting to reach for when tests run npm install or call a local service, rather than full access:

toml
[sandbox_workspace_write]
network_access = true

[features.network_proxy] goes one step further and limits which domains commands reach. It doesn't open the network on its own, deny beats allow, and web search, MCP connections and Codex's own model requests pass outside it:

toml
[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

## Auto-review #

By default approvals_reviewer = "user" and approval requests come to you. With "auto_review" the eligible ones go to Codex's reviewer. It sees only what would have asked you anyway, and needs an interactive policy: on-request or granular.

## Which mode for which job #

| Job | Setup | Why |
| --- | --- | --- |
| Reading an unfamiliar repository | read-only | Nothing can change while you look around |
| Everyday coding in your own project | workspace-write + on-request | Edits go ahead; anything outside the project asks |
| An unattended run in a throwaway container or VM | workspace-write + never , or full access inside the box | Nobody is there to answer; the box is the boundary |
| Your laptop with real credentials | Never --yolo | Full access reaches your SSH keys, tokens and other projects |

With full access, a bad command is not the only risk: a web page or issue Codex reads can carry instructions too ([prompt injection and coding agents](https://shuriken.sh/guides/prompt-injection-coding-agents)). Claude Code makes the same trade-off with its own settings, described in [Claude Code permission rules](https://shuriken.sh/guides/claude-code-permission-rules) and [skipping permissions safely](https://shuriken.sh/guides/skip-permissions-safely).

## Codex in Shuriken #

A Codex chat in Shuriken has three modes, each a pair from the tables above. Default Permissions asks Codex for workspace-write with on-request. Full Access asks for danger-full-access with never. Auto-review is Default Permissions with approvals_reviewer = "auto_review"; Shuriken only offers it when the installed Codex is 0.115.0 or newer, and then makes it the default. Every chat except a project's Main chat also works in its own git worktree, a separate checkout on its own branch. That keeps one chat's edits out of another's files, but a worktree is not a sandbox: what Codex may do is still set by these two settings.

Share

[X](https://x.com/intent/post?url=https%3A%2F%2Fshuriken.sh%2Fguides%2Fcodex-cli-approval-modes&text=Codex%20CLI%20approval%20modes%20and%20sandbox%2C%20explained)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fshuriken.sh%2Fguides%2Fcodex-cli-approval-modes)[Hacker News](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fshuriken.sh%2Fguides%2Fcodex-cli-approval-modes&t=Codex%20CLI%20approval%20modes%20and%20sandbox%2C%20explained)[Reddit](https://www.reddit.com/submit?url=https%3A%2F%2Fshuriken.sh%2Fguides%2Fcodex-cli-approval-modes&title=Codex%20CLI%20approval%20modes%20and%20sandbox%2C%20explained)[E-mail](mailto:?subject=Codex%20CLI%20approval%20modes%20and%20sandbox%2C%20explained&body=https%3A%2F%2Fshuriken.sh%2Fguides%2Fcodex-cli-approval-modes)

## Sources

- [OpenAI: Agent approvals and security](https://learn.chatgpt.com/docs/agent-approvals-security) (accessed 25 October 2026)
- [OpenAI: Codex config basics](https://learn.chatgpt.com/docs/config-file/config-basic) (accessed 23 October 2026)

## Frequently asked questions

**What is the default Codex approval mode?**

Auto, if the folder is a git repository: workspace-write plus on-request, so Codex edits and runs commands in the project by itself and asks before writing outside it or using the network. Outside version control Codex suggests read-only instead.

**What does --yolo do in Codex?**

Its long name is --dangerously-bypass-approvals-and-sandbox, and it does what that says: no sandbox, no prompts. OpenAI's table marks it not recommended. It also makes web search fetch live pages instead of the cached index.

**Can Codex use the internet in workspace-write mode?**

Not by default. Under [sandbox_workspace_write] in config.toml, network_access = true lets commands go online while the rest of the workspace-write sandbox stays in place.

**Why does Codex refuse to start with approval_policy untrusted?**

Because OpenAI retired that value, and the approvals page warns it can stop Codex from starting. Delete the line. If you liked being asked before every command, put trust_level = "untrusted" in that project's [projects."..."] table in your user config.

Every coding agent

67 coding agents, one harness.

Run Claude Code, Codex, Gemini CLI and the rest on your own computers, with the sign-ins you already have.

[Download](https://shuriken.sh/download)

[Other platforms](https://shuriken.sh/download#main)

## Keep reading

- [How to choose an app for your coding agents: Guide 27 Oct 2026 4 min read Picking an app to run Claude Code, Codex and other agents? Eight questions that separate them: where agents run, your plans, worktrees, limits and privacy.](https://shuriken.sh/guides/choose-a-coding-agent-app)
- [Can you use your Claude plan in OpenCode or other tools?: Guide 27 Oct 2026 6 min read Not in OpenCode. Anthropic keeps Pro and Max sign-ins for Claude Code and its own apps, and OpenCode dropped its Claude plugins in 1.3.0. Use an API key.](https://shuriken.sh/guides/claude-subscription-in-other-tools)
- [Codex "stream disconnected before completion": fixes: Guide 27 Oct 2026 5 min read Codex shows stream disconnected before completion when OpenAI's streamed reply breaks off. It retries 5 times, then stops the turn. How to find the cause.](https://shuriken.sh/guides/codex-stream-disconnected-before-completion)

## Free tools

- [Claude limit reset tracker](https://shuriken.sh/tools/limit-resets/claude)
- [Codex limit reset tracker](https://shuriken.sh/tools/limit-resets/codex)