Codex Auto Mode: How to Turn On 'Approve for Me', and Why It Still Asks

OpenAI's Codex (the CLI, the desktop app and the IDE extension) has no setting called "auto mode", as of Codex 0.166.0. What people mean is Approve for me, which the docs also call Auto-review: Codex keeps the same workspace-write sandbox as its default mode, but when it needs to cross that sandbox, a separate reviewer agent approves or denies the request instead of you. Turn it on with codex --approve-for-me, with approvals_reviewer = "auto_review" in ~/.codex/config.toml, or by choosing Approve for me in the permissions control under the composer. The old --full-auto flag is gone: 0.147.0 removed it from codex exec, and the 0.166.0 build has no trace of it.

Last reviewed 5 November 2026, against Codex 0.166.0. Settings and behavior are from OpenAI's Codex docs and the release notes; flag names and on-screen text are quoted from the 0.166.0 Linux package, which I downloaded from npm and searched without running it. I couldn't run a signed-in Codex session for this post, so nothing here claims a first-hand test of the reviewer's decisions.

Is there an auto mode in Codex?

Not by that name, but Approve for me does the job. Codex has two separate controls. The sandbox decides what Codex can do on its own (read files, edit the workspace, use the network). The approval policy decides when it has to stop and ask. In the default mode, called Ask for approval in the app and Default in the 0.166.0 CLI picker, Codex edits files and runs commands inside your workspace without asking, and asks you before it crosses that boundary. OpenAI's approvals and security page calls this same default the Auto preset, which is part of the confusion: that preset is not Approve for me, because you still answer every request to cross the sandbox.

Approve for me keeps all of that and changes one thing: who answers. From the Auto-review docs:

Auto-review replaces manual approval at the sandbox boundary with a separate reviewer agent. The main Codex agent still runs inside the same sandbox, with the same approval policy and the same network and filesystem limits.

So if you came from Claude Code looking for "auto mode", Approve for me is the equivalent: fewer prompts, with a model checking the risky steps. The difference is in what gets checked, which the comparison below covers.

How do I turn on auto mode (Approve for me) in Codex?

Use codex --approve-for-me for one session, /permissions inside a running session, or approval_policy = "on-request" plus approvals_reviewer = "auto_review" in ~/.codex/config.toml to make it your default. In the app or IDE extension, choose Approve for me in the permissions control under the composer, chat by chat.

In the app or the IDE extension

Open the permissions control below the composer and choose Approve for me. The setting is per chat, so check it's selected in the chat you're working in; the docs warn that "having a mode available doesn't mean it's selected." If it isn't in the list, see Approve for me is missing.

In the CLI, for one session

Start Codex with codex --approve-for-me. The 0.166.0 build describes the flag as:

Route approval requests through automatic review using the workspace-write sandbox

Or, in a running session, type /permissions and pick Approve for me. Since 0.164.0 you can also do it in one line:

/permissions :workspace --approval-policy=on-request --reviewer=auto_review

For every session: config.toml

Add both keys to ~/.codex/config.toml:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Both matter. The docs are explicit that "changing the approval policy alone doesn't select the reviewer," and the reviewer only runs when approvals are interactive: with approval_policy = "never", there is nothing to review. For a one-off run without editing the file, -c approvals_reviewer=auto_review on the command line does the same, as long as your approval policy is still on-request.

What does Approve for me actually review?

Only the actions that would otherwise stop and wait for you. Per the Auto-review docs, that means:

• shell or exec calls that ask for escalated sandbox permissions
• network requests the sandbox or policy blocked
• file edits outside the writable folders
• MCP or app tool calls that need approval because of their annotations or your settings

Everything that already fits inside the sandbox runs without a review step: editing files in the workspace, running your tests, reading the repo. That's why most of a session never reaches the reviewer. Computer Use is an exception: its app approvals still come to you.

The reviewer is itself a Codex agent. It sees a compact transcript (your messages, Codex's visible updates, relevant tool calls and their output) plus the exact request, but not Codex's hidden reasoning. It's built to block four kinds of action: sending private data or credentials to untrusted places, probing for credentials or tokens, broad or lasting security weakening, and destructive actions that are hard to undo. The full policy is public in the Codex repository as policy.md, and you can replace it with your own text under [auto_review] policy in config.toml. If you do, copy the whole default policy first: a custom policy replaces it rather than adding to it.

How is Approve for me different from Ask for approval and Full access?

Approve for me and Ask for approval share the same workspace-write sandbox; the only difference is whether a reviewer agent or you answer requests to cross it. Full access removes the sandbox, so nothing is reviewed at all.

The jump from Approve for me to Full access is much bigger than it looks in the menu. Full access removes the sandbox, so there's no boundary left for anything to review. The help text for the flag reads:

Skip all confirmation prompts and execute commands without sandboxing. EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed

When you choose full access, Codex 0.166.0 warns that it "can edit any file on your computer and run commands with network, without your approval" and adds: We strongly recommend selecting "Approve for me" instead, and customizing the reviewer policy for your use case. Keep Full access for containers or VMs you can throw away. That advice isn't Codex-specific: an agent with no sandbox can delete files outside the project.

What happened to --full-auto?

It was removed in Codex 0.147.0, released on 7 August 2026. The release notes say: "Remove the deprecated codex exec --full-auto flag; use --sandbox workspace-write instead." The same release added --approve-for-me. Neither full-auto nor full_auto appears anywhere in the 0.166.0 build, so scripts and guides that still pass it should now stop with an unknown-argument error (I couldn't run Codex to confirm the exact message).

What to use instead depends on what --full-auto meant to you:

• "Work in my repo without asking": plain codex, which is already workspace-write with on-request approvals.
• "Also stop asking me about the risky steps": codex --approve-for-me.
• "Run unattended in CI": codex exec --sandbox workspace-write. Add --ask-for-approval never (-a never) when nothing should wait for a person; failures then go straight back to the model.

Two more retirements catch people out. approval_policy = "untrusted" is no longer supported since 0.149.0, and the docs warn that it "can prevent either client from starting", so remove it from config files and profiles. on-failure is deprecated. The supported values are on-request, never and a granular policy.

Why does Codex still ask for approval in auto mode?

Either the chat is still in Ask for approval, so you are the reviewer, or the request is outside what Auto-review changes: network access is off by default, folders outside the workspace aren't writable, .git, .codex, .agents and .aws stay read-only, and Computer Use app approvals always come to you. The two cases have different fixes.

You're actually in the default mode. If a prompt such as Would you like to run the following command? or Would you like to make the following edits? appears, the reviewer is you. Check the permissions control or the status line for Approve for me. In the app it's set per chat, and approval_policy = "never" or a granular policy that hides a prompt category means Auto-review never sees those requests.

The request is outside what Approve for me covers. Auto-review swaps the reviewer; it doesn't grant anything. These still need a decision or a setting change:

• Network access. It's off in workspace-write by default, so every networked command is a crossing. If you trust the repo, turn it on:

  tomlCopy

  [sandbox_workspace_write]
  network_access = true

• Files outside the workspace. Add the folders you need with --add-dir, or list them in writable_roots, instead of approving each write.

• Protected paths. Inside a writable folder, .git, .codex, .agents and .aws stay read-only in workspace-write, so writes there are always crossings.

• Destructive MCP and app tools. A tool that advertises a destructive annotation always needs approval. In Approve for me that approval goes to the reviewer; in the default mode it comes to you.

• Computer Use. Its app approvals come to you directly.

OpenAI's own advice is to fix the boundary instead of training the reviewer to wave things through: add narrow writable_roots and precise command rules such as ["cargo", "test"] or ["pnpm", "run", "lint"], and avoid broad ones like ["python"] or ["curl"], which "often erase the boundary Auto-review is meant to guard."

Why did Auto-review deny my command, and how do I override it?

A denial is deliberate, not an error. When the reviewer says no, Codex passes its rationale to the main agent with an instruction not to reach the same goal by a workaround, to continue only with "a materially safer alternative," and otherwise to stop and ask you. If the reviewer gave no reason, the 0.166.0 build shows Auto-reviewer denied the action without a specific rationale.

To override one denial in the CLI:

1. Type /approve.
2. Pick the action from the Auto-review Denials list. Per the Auto-review docs, Codex keeps up to 10 recent denials per task.
3. Confirm. Codex retries that exact action once.

The override is narrow on purpose. It covers that action only, not similar ones later, and the retry still goes through Auto-review, which "can deny again if policy says the user cannot overwrite that class of denial."

Two limits worth knowing:

• There's a circuit breaker. According to the Auto-review docs, it stops the turn after 3 denials in a row, or 10 denials within the last 50 reviews in the same turn. If a turn ends with a warning after several denials, that's why.
• The desktop app has no /approve. As of 5 November 2026, open issues report the reviewer rejecting actions the user had clearly authorized in chat, with no way to override in the app: #58401, #58501 and #58855. Until that changes, switch the chat to Ask for approval, approve the one action yourself, and switch back.

Why is Approve for me missing or disabled?

Usually an outdated app or CLI, an explicit features.guardian_approval = false in your effective config, or an admin policy that doesn't allow the auto_review reviewer. Local settings can't override a managed policy. OpenAI's troubleshooting page lists three checks:

1. Update, then look at the permissions menu in the chat where you want it. Local and cloud environments can offer different choices.
2. Check your effective local config for an explicit features.guardian_approval = false, and check the permission profile, approval policy and reviewer you've set.
3. Ask your admin if you're in a managed workspace. Organizations can restrict the allowed permission profiles, sandbox modes, approval policies and reviewers (allowed_approvals_reviewers), and local settings can't override that.

The app and the CLI can ship different Codex versions, so a mode can appear in one before the other. Run codex --version for the CLI.

Does Approve for me use more tokens?

Yes, it can. The approvals and security docs say plainly that "automatic review uses extra model calls, so it can add to Codex usage." The reviewer only runs for actions that already need approval, so the extra cost tracks how often your work crosses the sandbox, not how many commands Codex runs. A session that installs packages and calls APIs all day will pay for more reviews than one that edits and tests inside the repo. Turning on network access for a repo you trust removes most of those crossings. To put a figure on a session, plug its token counts into an LLM cost calculator.

Is Codex auto mode the same as Claude Code auto mode?

Same goal, different design. Both cut prompts by letting a second model judge risky steps. They draw the line in different places.

In practice, Codex's sandbox does most of the work and the reviewer handles the exceptions, while Claude Code's classifier sees most commands. If you use both, the Claude side is covered in Claude Code auto mode is now the default, and how Claude Code's optional sandbox compares is in the Claude Code sandbox guide.

What changed in Codex approvals recently?

Between 0.146.1 and 0.166.0 (August to October 2026), Codex added --approve-for-me, removed --full-auto, retired the untrusted policy and let /permissions set the reviewer inline.

The dates are the dates on Codex's GitHub releases. One more change sits outside the table: per the Auto-review docs, choosing an approved Daybreak (cyber) model in the app switches the chat to Approve for me, and the 0.166.0 build explains it with Cyber models default to "Approve for me" for safety reasons.

FAQ

Related

• Claude Code auto mode is now the default: turn it off, or keep it
• The Claude Code sandbox: what it blocks and how to set it up
• Claude Code deleted my files: what happened and how to stop it
• Codex Crashpad 'pending' eating your Mac's disk