Codex CLI approval modes versus sandbox modes: safe combinations for autonomous runs

Codex CLI's safety comes from two independent settings: the approval policy and the sandbox. Mixing them up leads to confusion such as "I turned off prompts but the command still fails" or "it asked me, yet the file was already changed".

This article explains each option, what happens when they combine, and which pair to use for which job.

Two settings, two jobs

Setting	Decides	Enforced by
approval	Whether to ask you before an action	Codex's conversation flow
sandbox	What a running command may do at the OS level	OS mechanisms: Seatbelt on macOS, Landlock/seccomp on Linux

Approval is "do we ask"; sandbox is "is it possible". Skip every prompt and a read-only sandbox still prevents writes. Open the sandbox completely and per-action prompts still let you stop things.

Approval policies

Set with --ask-for-approval (short -a) or approval_policy in config.toml.

Value	Meaning
untrusted	Prompt for everything except commands judged safe and read-only. Most conservative
on-request	Prompt only when Codex decides it needs to (close to the default)
on-failure	Run inside the sandbox; ask only when a command fails, whether to retry outside the sandbox
never	Never prompt; carry on even after failures. For CI

Sandbox modes

Set with --sandbox or sandbox_mode in config.toml.

Value	Read files	Write files	Network
read-only	Yes	No	No
workspace-write	Yes	Only inside the workspace (current directory) and temp dirs	Off by default (configurable)
danger-full-access	Yes	Anywhere	Yes

Even in workspace-write, direct writes to .git may be restricted. Git operations run as normal commands, so this rarely matters.

What --full-auto expands to

--full-auto is shorthand for workspace-write plus reduced prompting. Writes outside the workspace and network access remain blocked, so think of it as "do what you like inside the workspace".

codex --full-auto "Refactor until the tests pass"

Recommended combinations

Job	approval	sandbox	Notes
Exploring or asking about code	on-request	read-only	Nothing can be changed by accident
Daily development	on-request	workspace-write	Close to the defaults; side effects get confirmed
Long autonomous tasks (local)	on-failure	workspace-write	You decide only on failures
CI or containers	never	workspace-write or danger-full-access	Assumes a throwaway environment

Pinning them in config.toml

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

[sandbox_workspace_write]
# set to true when npm install and similar need the network
network_access = false

Profiles let you switch per task with --profile:

[profiles.readonly]
approval_policy = "on-request"
sandbox_mode = "read-only"

[profiles.auto]
approval_policy = "on-failure"
sandbox_mode = "workspace-write"

codex --profile readonly "Find every caller of this function"
codex --profile auto "Fix all the lint errors"

Profiles are covered in depth in Switching models and profiles in Codex's config.toml.

Switching mid-session

The /approvals command changes the approval mode during a session, handy when a research session turns into implementation.

How this compares with Claude Code

Claude Code has no OS-level sandbox; it uses per-tool rules (allow / deny / ask). Both aim to stop dangerous commands, but Codex enforces limits physically through the OS while Claude Code controls them through rules.

Summary

• Approval is "do we ask"; sandbox is "what can the OS allow". They are independent
• Daily work: on-request + workspace-write; research: read-only; CI: never
• --full-auto is workspace-write with fewer prompts; outside writes and network stay blocked
• danger-full-access with never is for isolated environments only

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true