Codex Auto-review：让审查代理处理沙箱边界审批

适用场景

Auto-review 适合希望减少人工审批打断，但仍然保留沙箱边界的团队。它不是“自动放权”，而是让一个单独的 reviewer agent 替代人来审查某些边界穿越请求。

如果你的目标是完全禁用审批，Auto-review 不是合适工具。它的定位是审查，而不是跳过审查。

工作方式

官方文档描述的流程可以简化成：

1. 主 Codex agent 在 read-only 或 workspace-write 之类沙箱里工作。
2. 当它需要越过边界时，请求 approval。
3. 如果配置了 approvals_reviewer = "auto_review"，请求会交给 reviewer agent。
4. reviewer 判断这个动作是否应该执行，并返回理由。
5. 如果批准，任务继续；如果拒绝，主 agent 必须寻找更安全方案，或停止并询问用户。

关键点：沙箱不变，审批策略不变，变化的是谁来审查请求。

什么时候会触发

Auto-review 只审查原本会暂停等待人工确认的动作，例如：

• shell 或 exec 工具请求 escalated sandbox permissions。
• 当前沙箱或策略阻止的网络请求。
• 试图编辑 writable roots 之外的文件。
• MCP 或 app tool 根据注解或审批模式需要确认。
• Browser Use 访问新网站或新域名。

如果动作已经被当前 sandbox 允许，就不会触发 Auto-review。

Computer Use 是单独情况。官方文档说明 Computer Use 的 app-level approvals 仍然直接展示给用户，Auto-review 不会替代这些提示。

Auto-review 重点阻止什么

它主要用于拦截高风险动作，例如：

• 把私有数据、密钥或凭证发往不可信目的地。
• 查找 tokens、cookies、session 等敏感材料。
• 大范围或持久削弱安全设置。
• 高风险、不可逆的破坏性操作。

被拒绝后，Codex 不能通过绕路继续追求同一结果。它必须换一个实质更安全的方案，或者停下来询问用户。

配置方式

企业可以通过 managed configuration 配置 reviewer policy。个人用户也可以在本地 config.toml 中配置 Auto-review policy，例如：

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

如果企业 managed requirements 已配置策略，它通常会优先于个人本地配置。

减少审批噪音

如果 Auto-review 频繁处理低风险请求，不要只靠 policy 盲目放宽。更好的做法是调整沙箱边界：

• 把常用安全目录加入允许范围。
• 把验证命令设计在工作区内完成。
• 使用更明确的 project setup，减少临时联网安装。
• 对高频内部工具使用 MCP 或插件的明确权限模型。

审批太多往往说明边界设计需要优化。

常见错误

不要把 Auto-review 当成“无监督模式”。它只是审查者变化，不是权限变化。

不要把 policy 写得过宽。过宽的 policy 会把原本应该拦住的敏感动作放过去。

不要在被 Auto-review 拒绝后让 Codex 用 workaround 绕过。官方行为要求拒绝后只能换更安全方案或停止询问。

小结

Auto-review 的价值是减少边界审批对工作流的打断，同时保留沙箱、审批和策略控制。它适合团队治理场景，尤其适合已经有明确权限边界、希望把人工审批集中到真正高风险动作上的团队。