Auto-review 会在 sandbox boundary 处用一个独立 reviewer agent 替代 manual approval。Main Codex agent 仍在同一个 sandbox 内运行，具有相同的 approval policy，以及相同的 network 和 filesystem limits。区别在于由谁 review eligible escalation requests。
Auto-review 只在 approvals 是 interactive 时适用。实践中，这意味着 approval_policy = "on-request"，或仍会显示相关 prompt category 的 granular approval policy。使用 approval_policy = "never" 时，没有任何内容需要 review。
Auto-review 如何工作
从 high level 看，流程是：
Main agent 在 read-only 或 workspace-write 内工作。
当它需要越过 sandbox boundary 时，会请求 approval。
如果 approvals_reviewer = "auto_review"，Codex 会把该 approval request 路由给一个独立 reviewer agent，而不是停下来等待人处理。
Reviewer 决定该 action 是否应该运行，并返回 rationale。
如果 action 被 approved，execution 会继续。如果被 denied，main agent 会被指示寻找 materially safer path，或停下来询问 user。
Auto-review 是 reviewer swap，不是 permission grant。它不会扩大 writable_roots、启用 network access，也不会削弱 protected paths。它只改变 Codex 如何处理那些已经需要 approval 的 actions。
何时触发
Auto-review 会评估本来需要暂停等待 human 的 approval requests。这些包括：
请求 escalated sandbox permissions 的 shell 或 exec tool calls。
被当前 sandbox 或 policy 阻止的 network requests。
allowed writable roots 外的 file edits。
根据 tool annotations 或 configured approval mode 需要 approval 的 MCP 或 app tool calls。
Browser Use 访问新 website 或 domain。
Auto-review 不会为 sandbox 内已经允许的 routine actions 运行。如果某个 command 可以在 active sandbox_mode 下运行，或 tool call 留在 allowed policy 内，main agent 会不经 review 继续。
Computer Use 是单独情况。Computer Use 的 app approvals 仍会直接呈现给 user，因此 Auto-review 不会替代这些 app-level prompts。
Auto-review 会阻止什么
从 high level 看，Auto-review 设计用于阻止这类 actions：
向 untrusted destinations 发送 private data、secrets 或 credentials。
探测 credentials、tokens、cookies 或 session material。
广泛或持久的 security weakening。
具有重大 irreversible damage 风险的 destructive actions。
精确 policy 位于 open-source Codex repository： policy_template.md 和 policy.md 。该 policy 可以由 enterprise 通过 guardian_policy_config 定制，也可以由 user 通过 local [auto_review].policy 定制。
Reviewer 会看到什么
Reviewer 本身也是一个 Codex agent，但它的 job 比 main agent 更窄：判断某个具体 boundary-crossing action 是否应该运行。
Reviewer 会看到 compact transcript 和 exact approval request。通常包括 user messages、surfaced assistant updates、相关 tool calls 和 tool outputs，以及当前被 proposed for approval 的 action。它也可以执行 read-only checks 来收集缺失 context，但很少这样做。
Hidden assistant reasoning 不会被包含。Auto-review 看到的是 retained conversation items 和 tool evidence，而不是 private chain-of-thought。
Denials 和 failure behavior
Explicit denial 不会被当作普通 sandbox error。Codex 会把 review rationale 返回给 main agent，并添加更强的 instruction：
不要通过 workaround、indirect execution 或 policy circumvention 追求相同 outcome。
只在有 materially safer alternative 时继续。
否则停下来询问 user。
Codex 还会对每个 turn 应用 rejection circuit breaker。在当前 open-source implementation 中，Auto-review 会在同一 turn 连续 3 次 denials，或最近 50 次 reviews rolling window 内出现 10 次 denials 后 interrupt turn。
任何 non-denial 都会重置 consecutive-denial counter。当 breaker trips 时，Codex 会发出 warning，并以 interrupt abort 当前 turn，而不是让 agent 在更多 escalation attempts 上循环。
Timeouts 会与 explicit denials 分开 surfaced，main agent 会被告知 timeout 本身并不能证明该 action unsafe。
Denied actions 还有一个 explicit override path。在当前 open-source TUI 中，运行 /approve 打开 Auto-review Denials picker，然后选择一个 recent denied action，为一次 retry 进行 approve。Codex 每个 thread 最多记录 10 个 recent denials。该 approval 范围很窄：只适用于 exact denied action，不适用于相似的 future actions；它只记录为 same context 中的一次 retry；并且 retry 仍会经过 Auto-review。底层实现中，Codex 会为该 exact action 注入 developer-scoped approval marker。Reviewer 随后会把这个 explicit user override 作为 context 看到，但仍会遵循 policy；如果 policy 认为 user 不能覆盖该类 denial，它仍可再次 deny。
Configuration
Setup details 请参见 Managed configuration 。
Default reviewer policy 位于 open-source Codex repository： core/src/guardian/policy.md 。Enterprises 可以在 managed requirements 中用 guardian_policy_config 替换其 tenant-specific section。Individual users 也可以在 config.toml 中设置 local [auto_review].policy ，但 managed requirements 优先：
[auto_review]
policy = """
YOUR POLICY GOES HERE
"""要 customize policy，请先复制完整 default policy wording，然后基于你的 individual risk profile 迭代。
在不削弱 security 的情况下降低 review volume
当 sandbox 已覆盖常见 safe workflows 时，Auto-review 效果最好。如果太多 mundane actions 需要 review，应先修正 boundary，而不是教 reviewer 永久 approve noisy escalations。
实践中，leverage 最高的改动是：
为你有意使用的 scratch directories 或 neighboring repos 添加 narrow writable_roots 。
添加 narrowly scoped prefix rules 。优先使用精确 command prefixes，例如 ["cargo", "test"] 或 ["pnpm", "run", "lint"]，而不是 ["python"] 或 ["curl"] 这类 broad patterns。Broad rules 往往会抹掉 Auto-review 本来要守住的 boundary。
Auto-review session transcripts 默认保留在 ~/.codex/sessions 下，因此你可以在更改 policy 或 permissions 前，让 Codex 分析那里的 past traffic。
Limits
Auto-review 会改善 long-running agentic work 的 default operating point，但它不是 deterministic security guarantee。
它只评估请求 cross a boundary 的 actions。
它仍然可能出错，尤其是在 adversarial 或 unusual contexts 中。
它应 complement，而不是 replace，良好的 sandbox design、monitoring 和 organization-specific policy。
关于 research rationale 和已发布 evaluation results，请参见 Alignment Research post on Auto-review 。