Codex approval modes: full auto, YOLO mode and approval_policy

Q: What is the default approval mode in Codex?

In a Git repository Codex recommends Auto: the workspace-write sandbox with on-request approvals. Outside version control it recommends read-only. Type /status in a session to see the policy that’s actually in effect.

Q: What does codex --yolo do?

--yolo is an alias for --dangerously-bypass-approvals-and-sandbox. Codex runs every command with no sandbox and never asks for approval. Use it only inside a container or VM you’re prepared to lose.

Q: Why is codex --full-auto not working?

Codex 0.163 removed it and rejects --full-auto as an unknown argument. Use --sandbox workspace-write --ask-for-approval on-request, the Auto preset Codex recommends for Git repositories, or --approve-for-me if you want a reviewer agent to answer the prompts.

Q: What is the difference between Codex full auto and YOLO mode?

Full auto kept the workspace-write sandbox and only skipped prompts for work inside it. YOLO mode (--yolo) removes the sandbox and every prompt, so commands can touch any file and the network.

Q: How do I give Codex network access without full access?

Keep the workspace-write sandbox and set network_access = true under [sandbox_workspace_write] in ~/.codex/config.toml. Edits stay limited to the workspace, and commands can reach the network.

Q: Why won’t Codex start after I set approval_policy = "untrusted"?

untrusted is retired as an approval policy and can stop Codex from starting. Remove it. For the old strict behavior, mark the project with trust_level = "untrusted" under [projects] in ~/.codex/config.toml instead.

Updated 24 October 2026

Before Codex runs a command, two settings decide what happens. The sandbox mode decides what the command can touch. The approval policy decides when Codex has to stop and ask you. Most complaints about Codex, too many prompts or a command that silently fails, come from mixing the two up. This guide covers both as they work in Codex CLI 0.163, including the flags and values that were renamed or removed.

The short answer

You want	Start Codex with	What happens
The normal setup (Auto)	`codex` in a Git repo, or `-s workspace-write -a on-request`	Edits files and runs commands in the project. Asks before writing outside it or using the network.
Look but don’t touch	`-s read-only -a on-request`	Reads files and runs commands that only read. Asks before anything the sandbox blocks, including edits.
Fewer prompts, same boundary	`--approve-for-me`	A reviewer agent answers the approval prompts instead of you.
Never stop (CI, scripts)	A profile with `approval_policy = "never"`	Never asks. Anything outside the sandbox fails and the error goes back to the model.
No limits at all	`--yolo`	No sandbox, no prompts. Only inside a container or VM.

Type /status in any session to see the approval policy and writable folders Codex is actually using.

Codex full auto: what replaced it

Older guides tell you to run codex --full-auto. That flag was removed: Codex 0.163 rejects it as an unexpected argument, and it no longer appears in codex --help. Full auto meant the workspace-write sandbox with on-request approvals, so the same command today is:

codex --sandbox workspace-write --ask-for-approval on-request

In a Git repository that’s already the Auto preset, so plain codex usually does the same. If what you wanted from full auto was fewer prompts, --approve-for-me keeps that sandbox and lets a reviewer agent answer them. Codex YOLO mode, --yolo, is not a replacement: it drops the sandbox as well as the prompts. To make the choice permanent, set approval_policy and sandbox_mode in config.toml (section 5, and the full Codex config.toml guide).

1. The two settings

Sandbox mode (sandbox_mode, or --sandbox / -s) is enforced by your operating system. It applies to the shell commands Codex runs, not to what the model can think about doing.

Value	Commands can
`read-only`	Read files. No writes, no network.
`workspace-write`	Read files, write inside the workspace (the project folder plus temp folders such as `/tmp`). No network unless you turn it on.
`danger-full-access`	Anything your user account can do. No sandbox.

Approval policy (approval_policy, or --ask-for-approval / -a) decides whether Codex can stop and ask you:

Value	Behavior
`on-request`	Codex works inside the sandbox without asking and asks when it needs to go past it. The model decides when to ask.
`never`	Codex never asks. If a command fails because of the sandbox, the failure goes straight back to the model.
`{ granular = { … } }`	Like `on-request`, but you choose which kinds of prompt can reach you. The rest are rejected automatically. Config file only.

Two values you’ll still see in older guides no longer work. untrusted is retired, and leaving it in your config can stop Codex from starting. on-failure is deprecated. The CLI flag only accepts on-request and never:

$ codex -a untrusted
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
  [possible values: on-request, never]

2. How they combine, and what each still asks about

The sandbox is the fence. The approval policy decides what happens when Codex wants to cross it. That’s why -a never on its own isn’t dangerous: with workspace-write the fence is still there, Codex just can’t ask to cross it.

Sandbox + approvals	Runs without asking	Still asks about
`read-only` + `on-request`	Reading files, read-only commands	Every edit, any command that writes or needs the network
`workspace-write` + `on-request`	Edits and commands inside the workspace	Writing outside the workspace, network access, commands matching a `prompt` rule, MCP and app tools that report side effects
`read-only` + `never`	Reading files, read-only commands	Nothing. Writes fail.
`workspace-write` + `never`	Edits and commands inside the workspace	Nothing. Network and outside writes fail.
`danger-full-access` + `never`	Everything	Nothing. This is what `--yolo` gives you.

A few things stay protected even in workspace-write: the .git, .codex, .agents and .aws folders inside a writable folder are read-only. Commands like git commit write to .git, so they need your approval even though they’re “inside the project”.

Destructive MCP and app tool calls ask for approval when the tool marks itself as destructive, whatever the sandbox. The sandbox only covers shell commands.

3. The current CLI flags

These are the approval and sandbox flags in codex --help for 0.163:

Flag	Effect
`-s`, `--sandbox`	`read-only`, `workspace-write` or `danger-full-access`
`-a`, `--ask-for-approval`	`on-request` or `never`. Interactive `codex` only.
`--approve-for-me` (alias `--not-so-yolo`)	`workspace-write` + `on-request`, with prompts sent to the automatic reviewer. Can’t be combined with `--sandbox` or `--yolo`.
`--dangerously-bypass-approvals-and-sandbox` (alias `--yolo`)	No sandbox and no prompts
`--add-dir <DIR>`	Makes another folder writable alongside the workspace
`-p`, `--profile <NAME>`	Loads `~/.codex/<NAME>.config.toml` on top of your config
`-c key=value`	Overrides any config key for this run

Two gotchas:

--full-auto is gone. Codex 0.163 rejects it as an unexpected argument, so old aliases and scripts that use it fail. Replace it with --sandbox workspace-write --ask-for-approval on-request, or just drop it in a Git repo.
codex exec has no -a flag. It takes --sandbox, --approve-for-me and --yolo, but for the approval policy use a profile or -c approval_policy='"never"'.

4. Change it mid-session with /permissions

Type /permissions in the Codex terminal app to open the picker. Choose Auto to let Codex work in the project, or Read Only when you want it to plan or explain without editing. Codex confirms the change and keeps it until you switch again. Older versions and guides call this command /approvals.

Related commands:

/status shows the model, approval policy and writable folders for this session.
/approve retries one action the automatic reviewer denied. It only matters with --approve-for-me or approvals_reviewer = "auto_review".
/debug-config prints which config layers loaded, which helps when a setting you wrote isn’t taking effect.

5. Set your defaults in config.toml

Flags only last for one run. For a default, put the keys at the top level of ~/.codex/config.toml, before any [table] header:

~/.codex/config.tomlapproval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "user"   # or "auto_review"

[sandbox_workspace_write]
network_access = false        # true lets commands reach the network
writable_roots = ["/Users/you/.cache/pip"]
exclude_slash_tmp = false
exclude_tmpdir_env_var = false

If a key lands under a table header by mistake, TOML reads it as part of that table and Codex ignores it. Codex prints a startup warning about unrecognized settings, and codex doctor names the exact key, for example sandbox_workspace_write.approval_policy is ignored. Start Codex with --strict-config to turn that into an error.

The granular policy keeps some prompts and rejects the rest without asking. Each true lets that kind of prompt reach you:

~/.codex/config.tomlapproval_policy = { granular = { sandbox_approval = true, rules = true, mcp_elicitations = true, request_permissions = false, skill_approval = false } }

Key	Covers
`sandbox_approval`	Requests to run a command outside the sandbox
`rules`	Commands that match a `prompt` rule
`mcp_elicitations`	Questions from MCP servers
`request_permissions`	Prompts from the `request_permissions` tool
`skill_approval`	Skill scripts that need approval

When the same key is set in several places, the highest one in this list wins:

CLI flags and -c overrides
.codex/config.toml in the project, closest folder first (trusted projects only)
The profile file you picked with --profile
~/.codex/config.toml
Config managed by your workspace, then /etc/codex/config.toml
Built-in defaults

On a work machine, an admin’s requirements.toml can forbid values outright, for example never or danger-full-access. No flag gets around that.

Codex also has beta permission profiles (default_permissions and [permissions.<name>]) that describe folders and network rules in more detail. They don’t mix with sandbox_mode: if sandbox_mode appears in any loaded config or you pass --sandbox, Codex uses the older settings and ignores the profile.

6. Save setups as profiles

A profile is a separate file next to your config. codex --profile ci loads ~/.codex/config.toml, then ~/.codex/ci.config.toml on top. Put keys at the top level of the file:

~/.codex/ci.config.tomlapproval_policy = "never"
sandbox_mode = "read-only"

~/.codex/auto.config.tomlapproval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

codex --profile auto
codex exec --profile ci "summarize the failing tests"

Since Codex 0.134, --profile no longer reads [profiles.<name>] tables in config.toml, and a top-level profile = "…" line is no longer supported. If your profile seems to do nothing, that’s why. Move each table into its own <name>.config.toml file and delete the old table.

7. Network access and extra folders

In workspace-write, commands have no network by default, so npm install, pip install or curl fail or trigger a prompt. To allow it without giving up the rest of the sandbox:

~/.codex/config.toml[sandbox_workspace_write]
network_access = true

For one run only: codex -c sandbox_workspace_write.network_access=true. This setting does nothing in read-only mode.

Turning the network on lets commands reach any host. To restrict them to certain domains, Codex has a network_proxy feature with allow and deny rules. Its rules apply only when the network is already on; adding them doesn’t turn the network on.

Web search is separate. Codex’s own search tool works without command network access and, by default, uses cached results rather than live pages. Set web_search = "live" or pass --search for live results, or "disabled" to turn it off. With --yolo, search defaults to live.

When Codex needs to write to a second folder, such as a sibling repo or a shared cache, add it with --add-dir ../other-repo or writable_roots. That keeps the sandbox, which is safer than switching to danger-full-access.

8. Trusted and untrusted projects

The first time you open a folder, Codex may ask if you trust it, and depending on your setup it can start in read-only until you do. Your answer is stored in ~/.codex/config.toml:

~/.codex/config.toml[projects."/Users/you/code/my-app"]
trust_level = "trusted"

Trust controls more than prompts. Codex loads a project’s .codex/config.toml, hooks and rules only when the project is trusted. A cloned repo can’t change your approval policy or run its own hooks until you say so.

Setting trust_level = "untrusted" is how you get the old untrusted approval behavior: commands need approval unless a rule allows them, and the project’s .codex folder is ignored. Leave approval_policy unset for this to work, because setting on-request explicitly overrides it.

9. Stop being asked about the same command

When you approve a command and tell Codex not to ask again, it saves a rule to ~/.codex/rules/default.rules. You can write rules yourself too. Each one matches the start of a command and says allow, prompt or forbidden. When several match, the strictest one wins:

~/.codex/rules/default.rulesprefix_rule(
    pattern = ["npm", "test"],
    decision = "allow",
    justification = "Tests are safe to run outside the sandbox",
)

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
)

Restart Codex after editing. Rules are experimental. Check a rule before relying on it:

$ codex execpolicy check --rules ~/.codex/rules/default.rules git push origin main
{"matchedRules":[{"prefixRuleMatch":{"matchedPrefix":["git","push"],"decision":"prompt"}}],"decision":"prompt"}

10. Test the sandbox, and OS differences

codex sandbox runs any command under the same sandbox Codex uses, so you can see what fails without starting a session. On macOS, from inside a project:

$ codex sandbox -c sandbox_mode='"workspace-write"' -- sh -c 'touch ./ok && echo wrote; curl -sI https://example.com || echo "no network"'
wrote
no network

Add -c sandbox_workspace_write.network_access=true and the same curl succeeds. Add --log-denials on macOS to print what the sandbox blocked.

macOS: Seatbelt (sandbox-exec). Works out of the box.
Linux: bwrap plus seccomp. Inside Docker it can fail if the container blocks namespaces or seccomp. The documented fix is to let the container be the boundary and run Codex with --sandbox danger-full-access inside it.
Windows: a native sandbox, with MXC preferred where your device supports it (prefer_mxc = true under [features]).
WSL: WSL2 uses the Linux sandbox. WSL1 stopped working in Codex 0.115.

11. Recommended setups

Day to day in a Git repo: the defaults, workspace-write + on-request. Add network_access = true if your work needs package installs. Work on a branch so you can throw away anything you don’t like.
Reviewing someone else’s code: read-only + on-request, and don’t trust the project until you’ve read its .codex folder.
Long unattended runs: --approve-for-me before you reach for --yolo. It keeps the sandbox and uses extra model calls to review each prompt. Or workspace-write + never, accepting that anything outside the project fails.
CI: codex exec with a profile that sets never and the narrowest sandbox the job can live with.
--yolo: only in a throwaway container or VM. Anything inside it, including your Codex credentials, is reachable by whatever the agent runs.

Answer Codex’s prompts from your browser

With on-request, Codex waits in the terminal until you answer, which is easy to miss when you’re in another window. Agent Pets turns each Codex session into a pet that walks along the bottom of every Chrome page:

When Codex asks for approval, its pet bounces. Click it and answer Allow or Deny from the page you’re on.
A capsule over each pet says Thinking, Your Turn or Done, and the toolbar badge counts the sessions waiting on you. Claude Code, OpenCode and omp sessions get pets too.
In another app, a desktop notification names the pet that needs you, with Allow and Deny on it.

npx getagentpets init adds hooks to ~/.codex/hooks.json; open Codex once and trust them with /hooks. Your approval policy and sandbox don’t change, and the terminal prompt keeps working. Everything runs on your computer.

Get Agent Pets — was $25, now $6Get Agent Pets — $25

Questions

What is the default approval mode in Codex?

In a Git repository Codex recommends Auto: the workspace-write sandbox with on-request approvals. Outside version control it recommends read-only. Type /status in a session to see the policy that’s actually in effect.

What does codex --yolo do?

--yolo is an alias for --dangerously-bypass-approvals-and-sandbox. Codex runs every command with no sandbox and never asks for approval. Use it only inside a container or VM you’re prepared to lose.

Why is codex --full-auto not working?

Codex 0.163 removed it and rejects --full-auto as an unknown argument. Use --sandbox workspace-write --ask-for-approval on-request, the Auto preset Codex recommends for Git repositories, or --approve-for-me if you want a reviewer agent to answer the prompts.

What is the difference between Codex full auto and YOLO mode?

Full auto kept the workspace-write sandbox and only skipped prompts for work inside it. YOLO mode (--yolo) removes the sandbox and every prompt, so commands can touch any file and the network.

What does approval_policy = "never" do in Codex?

Codex never stops to ask. The sandbox still applies, so anything it blocks fails and the error goes back to the model. Combine it with danger-full-access and you get the same thing as --yolo.

How do I give Codex network access without full access?

Keep the workspace-write sandbox and set network_access = true under [sandbox_workspace_write] in ~/.codex/config.toml. Edits stay limited to the workspace, and commands can reach the network.

Why won’t Codex start after I set approval_policy = "untrusted"?

untrusted is retired as an approval policy and can stop Codex from starting. Remove it. For the old strict behavior, mark the project with trust_level = "untrusted" under [projects] in ~/.codex/config.toml instead.

Sources: Codex documentation on agent approvals and security, sandboxing, config basics, advanced configuration, the configuration reference, the CLI reference, slash commands, permissions and rules; codex --help for Codex CLI 0.163.0.