Codex CLI permissions, sandbox, and approvals · AI coding agents

Codex’s safety model has two knobs: the sandbox (what commands are allowed to touch, enforced by the OS) and the approval policy (when Codex pauses to ask you). Configure them via --sandbox/-s and --ask-for-approval/-a, via sandbox_mode/approval_policy in config.toml, or mid-session with /permissions.

Approval policies

Policy	Behavior
`untrusted`	Only known-safe read operations run automatically; anything mutating or external requires approval
`on-request`	Codex asks when it needs to escalate beyond the sandbox (default for the interactive Auto preset)
`never`	Never ask; best effort within sandbox constraints — the right choice for non-interactive runs
`{ granular = {...} }`	Per-category allow/auto-reject: `sandbox_approval`, `rules`, `mcp_elicitations`, `request_permissions`, `skill_approval`

on-failure is deprecated — use on-request for interactive sessions or never for non-interactive ones.

Set approvals_reviewer = "auto_review" to route eligible approval prompts through an automatic reviewer agent instead of the user.

Sandbox modes

Mode	What Codex can do
`read-only`	Read files and answer questions; edits, commands, and network need approval
`workspace-write`	Read/edit/run inside the workspace; network off by default (`sandbox_workspace_write.network_access = true` to opt in); approval needed outside the workspace
`danger-full-access`	No filesystem or network sandbox — only for controlled environments

Protected paths

Even in workspace-write, these stay read-only: <root>/.git (including the resolved gitdir), <root>/.agents, and <root>/.codex (recursive). This is why git commit may still require approval in an otherwise writable workspace.

Verified presets and combos

Goal	Command
Auto preset (recommended for version-controlled folders)	`codex --sandbox workspace-write --ask-for-approval on-request`
Read-only exploration	`codex --sandbox read-only --ask-for-approval on-request`
CI read-only	`codex exec --sandbox read-only --ask-for-approval never "..."`
Edit files but approve untrusted commands	`codex --sandbox workspace-write --ask-for-approval untrusted`
Auto-review approvals	add `-c approvals_reviewer=auto_review`

Launch defaults: version-controlled folders get the recommended Auto preset; non-version-controlled folders start read-only; Codex may start read-only until the directory is trusted. /permissions changes the mode mid-session; /status shows the writable roots.

The codex exec flag --full-auto is a deprecated compatibility alias — it prints a warning; use --sandbox workspace-write instead.

WARNING: --dangerously-bypass-approvals-and-sandbox (alias --yolo) disables all approvals and the entire sandbox. Every command the model generates runs with your full user privileges. The official docs flag this as “Elevated Risk, not recommended” and say to use it only inside an externally hardened environment (a dedicated sandbox VM or a locked-down container). Never make it your default way of working. Side effect: web search defaults to live under full access. If you need more room, prefer --add-dir over danger-full-access, and prefer workspace-write for unattended local work.

Platform notes

macOS: Seatbelt via sandbox-exec, with a profile matching the mode; a curated platform policy is appended for tool compatibility.
Linux: bwrap (bubblewrap) + seccomp by default. Note an inconsistency in the official docs: the overview pages describe bwrap + seccomp, while the codex sandbox linux helper is described as running under “Landlock + seccomp” — the docs no longer describe Landlock as the primary mechanism for the agent sandbox, so the exact enforcement stack is not fully pinned down. WSL1 is unsupported since 0.115 (when the Linux sandbox moved to bwrap); WSL2 works.
Windows: native Windows sandbox ([windows] sandbox = "elevated" | "unelevated", sandbox_private_desktop), or the Linux sandbox under WSL2. IDE extension setting: chatgpt.runCodexInWindowsSubsystemForLinux.
Containers: if the environment blocks bwrap/seccomp, provide outer isolation (a devcontainer) and run --sandbox danger-full-access inside; the docs include a secure devcontainer reference with a firewall allowlist and warnings about credential exfiltration.

Test the sandbox locally:

codex sandbox macos|linux|windows [--permission-profile NAME] [-- COMMAND...]

(Aliases: codex debug, codex sandbox seatbelt, codex sandbox landlock.)

Fine-grained control: execpolicy rules (experimental)

.rules files (Starlark) live under a rules/ folder next to an active config layer — e.g. ~/.codex/rules/default.rules or <repo>/.codex/rules/ for trusted projects:

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    justification = "Pushing requires human confirmation",
)

Decisions are allow, prompt, or forbidden; the most restrictive decision wins (forbidden > prompt > allow). Shell chains with safe operators are parsed via tree-sitter and split per command; complex scripts are evaluated as a single bash -lc invocation. Test rules with codex execpolicy check --rules <file> -- <cmd>. Choosing “always allow” in the TUI writes to ~/.codex/rules/default.rules.

Network policy

Command network access is off by default. Enable it per mode (sandbox_workspace_write.network_access) and enforce domain rules with the experimental features.network_proxy: allowlist-first domain rules (*.example.com for subdomains only, **.example.com for apex + subdomains, * global; deny wins), allow_local_binding = false blocks loopback/private by default, SOCKS5 support, and dangerously_allow_non_loopback_proxy / dangerously_allow_all_unix_sockets escape hatches. The proxy does not filter web search, apps/connectors, MCP, browser, or model/auth traffic.

Web search is a separate knob: web_search = "cached" (default, OpenAI-maintained index), "indexed", "live", or "disabled".

Last verified: 2026-09-07

Official sources:

AI coding tools evolve quickly. If you find outdated information, please open an issue or pull request.