OpenAI Codex Approve for me (Auto-review)

OpenAI Codex Approve for me (Auto-review)

One-liner

Approve for me is the ChatGPT desktop / IDE permissions-menu label for Codex Auto-review: keep the same sandbox as Ask for approval (workspace-write + interactive on-request), but set approvals_reviewer = "auto_review" so a separate reviewer agent (guardian policy) decides eligible boundary-crossing approvals instead of you. It is a reviewer swap, not a permission grant — it does not widen writable roots, network, or Full Access.

Pin checked 2026-09-28 CST against developers.openai.com Auto-review, Permissions, Agent approvals & security, Config reference, Managed configuration, and Alignment Research (2026-04-30).

Not this note: a broad survey of approval_policy / “auto approve” / --yolo / Full Access. That older digest filename was deleted on purpose — do not recreate it.

---

Name map (UI ↔ config)

Surface label	Settings / docs name	Config / CLI
Approve for me (permissions menu under composer)	Auto-review (Settings > General > Permissions toggle)	approvals_reviewer = "auto_review"
Ask for approval	Default interactive mode	approvals_reviewer = "user" (default) + approval_policy = "on-request" + sandbox workspace-write / :workspace
Full access	Elevated risk; app warns and may recommend Approve for me	sandbox_mode = "danger-full-access" + approval_policy = "never" (or --yolo) — bypasses the approval requests Auto-review would see
Reviewer policy (Markdown)	Guardian / automatic review policy	[auto_review].policy locally; managed guardian_policy_config (wins over local); optional [auto_review].extra_policy / managed guardian_extra_policy
Org gate	Managed requirements	allowed_approvals_reviewers (e.g. ["auto_review"] or include "user")

Docs UI mapping (sandbox page): Ask for approval → Reviewer user; Approve for me → Reviewer auto_review, same sandbox/on-request posture.

---

What it is

Auto-review replaces who answers eligible approval prompts at the sandbox boundary:

1. Main agent works inside read-only or workspace-write (or equivalent permission profile).
2. Crossing the boundary creates an approval request.
3. With approvals_reviewer = "auto_review", Codex routes that request to a separate reviewer agent instead of pausing for a person.
4. Reviewer returns approve/deny + rationale.
5. Approve → run; deny → main agent must take a materially safer path or stop and ask the user (no workarounds / policy circumvention).

It only applies when approvals are interactive: approval_policy = "on-request" or a granular policy that still surfaces the relevant category. With approval_policy = "never", there is nothing to review.

---

What Auto-review decides vs what still prompts / sandbox still blocks

Reviewer evaluates (would have been human prompts)

Per Auto-review docs:

• Shell / exec calling for escalated sandbox permissions
• Network blocked by current sandbox or policy
• File edits outside allowed writable roots
• MCP / app tools that require approval (annotations or configured approval mode)
• Computer Use access to a new website or domain

Also called out on the approvals page: request_permissions prompts and side-effecting app/MCP calls that already need approval.

Policy themes (high level; exact text in OSS guardian policy): block private data/secrets to untrusted destinations, credential/token/cookie probing, broad/persistent security weakening, destructive irreversible damage. Approvals page: low/medium risk may proceed when policy allows; critical denied; high needs enough user authorization and no matching deny. Prompt-build / review-session / parse failures fail closed. Timeouts are separate — action still does not run.

Does not run for

• Routine actions already allowed inside the sandbox (no extra review step)
• Anything that never creates an interactive approval (e.g. never + full access / --yolo can avoid the boundary request review needs)

Still surfaces to the user (not replaced by Auto-review)

• Computer Use app-level approvals — docs: app approvals for Computer Use still go to the user; Auto-review does not replace those
• Modes org/policy disables (menu entry disabled)
• Explicit denial override path (TUI /approve — see below) still needs a human

Sandbox still enforces (unchanged by Approve for me)

• Writable roots / protected paths (e.g. .git, .agents, .codex under writable roots)
• Network off/on and proxy/domain rules
• Permission profiles (:read-only, :workspace, custom) — Auto-review does not expand them

---

How to enable

ChatGPT desktop app

1. Settings > General > Permissions — turn on Auto-review (adds Approve for me to the menu; does not by itself select the mode or change an existing chat).
2. Under the composer, open the permissions control → choose Approve for me.
3. Daybreak / approved security models: selecting an approved Daybreak model (including via /model) automatically switches the permissions control to Approve for me when available for the account and allowed by org policy; if unavailable, current mode stays. Model selection never overrides managed org requirements.
4. Before enabling Full access for an approved security model, the app shows a model-specific warning that recommends Approve for me and links to reviewer-policy config (warning does not restore sandbox or override org policy).

IDE extension

Permissions control beneath the composer — same menu labels when the mode is enabled/allowed.

CLI / config.toml

Minimal interactive Auto-review posture:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
# Prefer one of:
# sandbox_mode = "workspace-write"
# or default_permissions = ":workspace"  # don't combine with sandbox_mode / [sandbox_workspace_write]

Optional local policy (copy full current default first; blank ignored; managed wins):

[auto_review]
policy = """
# paste complete active reviewer policy, then add Environment Profile / tenant rules
"""
# optional additive layer:
# extra_policy = """..."""

One-shot CLI override (official approvals table):

codex --sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review

CLI permissions picker: /permissions. Denied Auto-review actions: TUI /approve → Auto-review Denials picker → one recent denial for one retry of the exact action (still goes through Auto-review; up to 10 recent denials per task recorded).

Enterprise / managed

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]   # or include "user" to allow choice

guardian_policy_config = """
## Environment Profile
...
## Tenant Risk Taxonomy and Allow/Deny Rules
...
"""

Managed guardian_policy_config replaces the tenant-specific section and takes precedence over [auto_review].policy. Keep an interactive approval policy and an enforceable sandbox; :danger-full-access / never / --yolo can skip the reviewable request. Network allowlists alone do not trigger review — use decision = "prompt" command rules or MCP tools that require approval when in-sandbox actions must still hit the reviewer.

---

Requirements, limits, risks

Topic	Fact
Prerequisite	Interactive approvals (on-request or granular with relevant categories on) + mode available / not blocked by allowed_approvals_reviewers
Cost	Extra model calls → can increase Codex usage
Circuit breaker (OSS docs)	Interrupt turn after 3 consecutive denials or 10 denials in last 50 reviews same turn
Transcripts	Auto-review session traffic under ~/.codex/sessions by default
Not a guarantee	Docs + Alignment post: mistakes possible; adversarial cases found in red-team; complements sandbox/monitoring, does not replace them
Scheming / in-sandbox harm	Auto-review only sees boundary escalations; in-sandbox or “benign-looking” escalations need other monitors
Reviewer model (Alignment, Apr 2026)	Published as GPT-5.4 Thinking (low reasoning) for that eval era — confirm live product if model ID matters
Reduce noise	Tighten sandbox first (writable_roots, narrow prefix rules) rather than teaching the reviewer to rubber-stamp escalations

Denial semantics: stronger than a normal sandbox error — no same-outcome workarounds; safer alternative or ask user.

---

Relation to approval_policy and sandbox (brief)

sandbox / permission profile  →  what is technically allowed without asking
approval_policy               →  whether / which categories create approval prompts
approvals_reviewer            →  who answers those prompts: user | auto_review

Approve for me ≈ Ask for approval sandbox + auto_review reviewer. It is not “auto approve everything” and not Full Access.

---

Sources

• https://developers.openai.com/codex/concepts/sandboxing/auto-review
• https://developers.openai.com/codex/permission-modes
• https://developers.openai.com/codex/sandboxing (and concepts sandboxing)
• https://developers.openai.com/codex/agent-approvals-security
• https://developers.openai.com/codex/config-reference (approvals_reviewer, [auto_review].*, apps/MCP reviewer overrides)
• https://developers.openai.com/codex/enterprise/managed-configuration (allowed_approvals_reviewers, guardian_policy_config)
• https://alignment.openai.com/auto-review/ (2026-04-30 research post + eval tables)
• Docs-linked OSS policy paths (cite; raw fetch was unavailable at pin time due to GitHub API rate limit / 404 on anonymous raw):
  https://github.com/openai/codex/blob/main/codex-rs/core/src/guardian/policy.md
https://github.com/openai/codex/blob/main/codex-rs/core/src/guardian/policy_template.md

---

Gaps / do-not-invent

• Did not paste guardian policy.md body (file not retrieved this pass).
• Did not document a --approve-for-me CLI flag — official docs show approvals_reviewer / -c approvals_reviewer=auto_review; third-party claims of --approve-for-me unverified here.
• Exact Daybreak model IDs / eligibility rules beyond “approved Daybreak model + account/org allow” not spelled out in the fetched pages.
• Per-app apps.*.approvals_reviewer overrides exist in config reference but are out of scope for this digest’s UI focus.