Codex — Part 7 — Approval Modes, Sandboxing, and config.toml
Codex’s safety model runs on two independent layers, what it can technically do and when it must stop and ask, and understanding the difference matters before you trust it on real infrastructure.
The technical boundary: what Codex is capable of doing, regardless of what it wants to do.
The human gate: when Codex has to stop and ask, even for something the sandbox would technically allow.
Where both settings live, alongside CLI flags that override them for a single run.
Introduction
Part 4 noted that AGENTS.md is context Codex tries to follow, not a hard guarantee. This post covers the two settings that are a hard guarantee: sandbox mode and approval policy, the same distinction the Claude Code series drew between CLAUDE.md and permission rules.
Two Independent Layers
Codex’s own documentation is direct about this: sandbox mode is what Codex can do technically, for example where it can write and whether it can reach the network. Approval policy is when Codex must ask you before it acts, for example before leaving the sandbox or running something outside a trusted set of commands. The two settings are configured separately and interact rather than substitute for each other.
Sandbox Modes
| Mode | What Codex Can Do |
|---|---|
read-only | File reading only. Edits, command execution, and network access are all blocked. |
workspace-write | File edits and command execution inside the active workspace. This is the default. |
danger-full-access | No sandbox enforcement at all, equivalent to the --yolo flag. |
Approval Policy Values
| Value | Behaviour |
|---|---|
untrusted | Only safe, read-only operations run automatically. Anything that changes state asks first. |
on-request | Codex asks when an action would exceed the sandbox’s boundaries. |
never | Disables approval prompts entirely. Use with real caution. |
granular | Selective control over which categories of prompt surface, such as sandbox escapes, MCP elicitations, or skill approval, set individually. |
Where Settings Live
# %USERPROFILE%\.codex\config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
# Allow network access while still writing only inside the workspace
[sandbox_workspace_write]
network_access = trueThe same settings are available as flags for a single run, useful for testing a stricter or looser configuration without editing the config file.
# Set approval behaviour for this run only
codex --ask-for-approval on-request --sandbox workspace-write
# Shorthand for disabling approval prompts
codex -a never
# Full access, no sandbox, no prompts: equivalent to danger-full-access
codex --dangerously-bypass-approvals-and-sandbox--dangerously-bypass-approvals-and-sandbox and --yolo the same way the Claude Code series treated bypassPermissions mode: appropriate for a disposable container or VM, not for a session touching production infrastructure.
Recommended Presets
Codex’s own documentation names two presets worth starting from rather than tuning settings from scratch.
| Preset | Settings | Use When |
|---|---|---|
| Locked down | --sandbox read-only --ask-for-approval on-request |
You want Codex to read and propose, never act, without you reviewing first |
| Automation-friendly | --sandbox workspace-write --ask-for-approval on-request |
Routine edits and commands inside a version-controlled project; this is the default preset for that case |
A Windows-Specific Layer
On Windows specifically, sandbox enforcement adds one more layer covered in Part 2: an elevated sandbox using a dedicated low-privilege user and firewall rules, or an unelevated fallback using a restricted token when administrator approval for the elevated setup is blocked. That Windows-level setting sits underneath sandbox_mode, controlling how the workspace boundary is actually enforced on that platform.
Final Thoughts
Sandbox mode and approval policy are not the same lever wearing two names. One decides what Codex is capable of; the other decides when a human has to say yes first. Both live in the same config.toml, both have single-run CLI overrides, and both are worth setting deliberately before pointing Codex at anything you would not want changed without a second look.
With the safety model covered, the next post turns to what to do when something in that configuration, or anywhere else, does not behave as documented.
--sandbox read-only --ask-for-approval on-request if you are not sure yet, and only move to workspace-write once you trust the specific project. Reserve danger-full-access and --yolo for disposable environments, not real infrastructure.
Next, a standing reference for common Codex problems beyond installation: sandbox setup failures, approval surprises, and sessions that behave unexpectedly.