Codex can hand its approval prompts to a reviewer agent. Here's how to set it up
Auto-review keeps the sandbox and swaps the human at the boundary for a second model. It has limits you should know before you turn it on.
Codex can stop asking you to approve every escalated command and let a second agent decide instead. It’s called auto-review, it’s a two-line config change, and it only helps if you understand what it does and doesn’t cover.
What changes
Codex still runs inside its sandbox. When the agent wants to cross a boundary, the request normally comes to you. With auto-review on, it goes to a reviewer agent instead, per OpenAI’s auto-review docs .
The reviewer sees a compact transcript (your messages, the agent’s updates, relevant tool calls) plus the exact request. It doesn’t see hidden reasoning.
The requests it handles are the ones that would have interrupted you: shell calls asking for escalated permissions, network requests the policy blocked, edits outside the writable roots, MCP or app tool calls that need approval, and Computer Use on a new domain.
Turn it on
In your Codex config.toml:
approval_policy = "on-request"
approvals_reviewer = "auto_review"
Both lines matter. Auto-review only works with on-request or a granular approval policy. With approval_policy = "never" nothing ever asks for approval, so there’s nothing to review. The default for approvals_reviewer is user, which is the behaviour you have today.
What it’s meant to stop
The docs say the reviewer targets four things: sending private data, secrets or credentials to untrusted destinations; probing for credentials, tokens, cookies or session material; broad or persistent security weakening; and destructive actions with a real risk of irreversible damage.
A command that posts your .env to an unknown host is the textbook case it exists to refuse. The docs don’t promise what it will wave through, so watch the first few sessions.
Tune the policy, carefully
You can override the reviewer’s rules locally:
[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE FIRST.
Then add your own rules below it.
"""
The docs are blunt about the workflow: copy the whole default policy wording first, then iterate. A short policy that replaces the default rather than extending it drops the protections you didn’t write down. Enterprise admins can set guardian_policy_config in requirements.toml, and that wins over a user’s local policy.
When it says no
A denial isn’t just a skipped command. Codex tells the agent not to chase the same outcome through a workaround, indirect execution or policy circumvention. If the reviewer denies three times in a row, or ten times within the last 50 reviews in one turn, a circuit breaker trips.
If the reviewer is wrong, type /approve in the TUI and pick one recent denied action for a single retry. The retry is still reviewed, so it’s not a bypass.
Where it doesn’t help
OpenAI is explicit that auto-review “is not a deterministic security guarantee”. It only looks at boundary-crossing actions, and a reviewer model can be fooled in adversarial situations, such as a prompt injection sitting in a file the agent reads. The docs give no latency or cost figures, so measure on your own workload before assuming it’s free.
My take: use it for long unattended runs where approval prompts are the bottleneck, and keep the sandbox tight so the reviewer is a second line, not the only one. If you’d rather have a rule that never gets argued with, a deterministic hook is the better tool, as the PreToolUse guardrail post shows for Claude Code.
Codex CLI 0.160.0 (October 1) also added opt-in Guardian review capabilities for pulling in earlier user instructions and context from agent handoffs, according to the Codex changelog . If your sessions involve subagents, that’s the release to be on.