Auto-review

Auto-review 是 Codex 在沙箱边界用独立审查 Agent 替代同步人工审批的机制。主 Agent 仍在原有 Agent Sandbox（Agent 沙箱）与审批策略内运行；当它请求越界执行时，请求被路由给审查 Agent，由后者决定批准、拒绝，并返回理由。

它不是扩大权限，而是审查者替换（reviewer swap）：不扩展 writable_roots、不默认打开网络、不放宽受保护路径，只改变“谁来审那些本来就要审批的动作”。OpenAI Alignment 在 2026 年 4 月公开了其设计、内部部署数据与安全评估；实现开源在 Codex 仓库的 guardian 策略中。

要解决的问题：审批摩擦反过来伤害安全

Codex 的默认权限模式（如 sandbox_mode = "workspace-write"、approval_policy = "on-request"、network_access = false）把读写与本地命令限制在可写根内；越界动作——常见如网络请求或简单 python 脚本——必须等人批准。

摩擦会把用户推向更危险的默认：

切到 Full Access：环境不再在沙箱边界强制规则；恶意执行、数据外泄、凭据探测等不再被本地边界挡住。
写过宽 prefix rules：内部流量里有相当一部分用户允许所有以 python 开头的命令；还有 codex exec --yolo 一类“永远放行”配置。
橡皮图章审批：疲劳或缺少命令细节理解时，人会不看就点通过。

生产长任务也不能每几分钟停一次去批准 curl。Auto-review 的定位是：在不默认 Full Access 的前提下，把越界审批从“人同步在线”变成“独立模型审查 + 必要时再找人”。

机制：沙箱内执行，边界上审查

flowchart TB
    U["用户任务"] --> M["主 Codex Agent\nread-only / workspace-write"]
    M -->|"沙箱内允许"| S["直接执行"]
    M -->|"越界：网络 / 沙箱外写 / 提权 shell / 需批 MCP"| R["Auto-review Agent\n独立调用"]
    R -->|"approve + 理由"| X["执行越界动作"]
    R -->|"deny + 理由"| M
    M -->|"更安全替代路径"| S
    R -->|"连续拒绝触发熔断"| H["停止并向用户升级"]

权限空间可以想成嵌套区域：

区域	谁决定	例子
沙箱内允许	环境策略，无需审查	`workspace-write` 下编辑仓库代码
rules 预授权	窄 prefix rules / `config.toml`	精确允许的 `cargo test`、`pnpm run lint`、`git pull`
Auto-review 审批	独立审查 Agent	查询数据库、重启实验、其他越界但可能合理的动作
yolo / Full Access 风险区	几乎无环境强制	数据外泄等本应由审查拦下的动作

要点：角色分离。主 Agent 被优化成完成用户任务，会把审批边界当成“又一个要克服的障碍”；Auto-review 的窄目标只是判断“这个越界动作该不该跑”。独立模型调用让策略更容易评估、监控和改进。

审查 Agent 通常看到：压缩后的 transcript、确切审批请求（用户消息、可见 assistant 更新、相关工具调用与输出、当前提议动作）。它可以做只读补上下文，但很少使用。隐藏的 chain-of-thought 不在视野内——只看保留的 chat item 与工具证据。

会审什么、不审什么

会进入 Auto-review 的，是本来就会暂停等人的请求，例如：

请求提权沙箱权限的 shell / exec
被当前沙箱或策略挡住的网络请求
允许可写根之外的文件编辑
按注解或配置需要审批的 MCP / app 工具调用
Computer Use 访问新网站或域名（应用级 Computer Use 审批仍直接给人，Auto-review 不替换那一层）

沙箱内已允许的日常动作不会再过一遍 Auto-review。若 approval_policy = "never"，也没有可审查对象——它只在交互式审批（如 on-request 或仍会弹出相关类别的细粒度策略）下生效。

拒绝不是普通沙箱错误

拒绝会把理由交回主 Agent，并附加强约束：

不要用绕道、间接执行或规避策略去追求同一结果
只允许实质更安全的替代路径
否则停下来问用户

开源实现里还有拒绝熔断：同一 turn 内连续 3 次拒绝，或最近 50 次审查中累计 10 次拒绝，会中断当前 turn，而不是让主 Agent 死循环刷审批。任意非拒绝会重置连续拒绝计数。超时与明确拒绝分开告知，超时本身不等于“动作不安全”。

TUI 里可用 /approve 从最近拒绝列表中挑一条做一次窄覆盖重试；覆盖只针对该精确动作，重试仍会再过 Auto-review，且策略仍可再次拒绝。

威胁模型与策略

Auto-review 旨在挡住会造成严重或难逆转伤害的动作，例如：

向不可信目的地发送私有数据、密钥或凭据
探测凭据、token、cookie 或会话材料
广泛或持久地削弱安全设置
高风险不可逆破坏
运行不可信代码，或遵循与用户指令冲突的不可信内容指令

它也会读用户意图：用户明确要求的“名义上有风险”动作可以批准。默认策略在 Codex 开源仓库的 guardian/policy.md；企业可用 guardian_policy_config 覆盖租户段，个人可在 config.toml 的 [auto_review].policy 写本地策略（托管要求优先）。

实践上，最高杠杆仍是先把沙箱边界设对：为常用安全工作流加窄 writable_roots 与精确 prefix rules，而不是教审查器永远批准嘈杂越界。过宽的 ["python"] / ["curl"] 会抹掉 Auto-review 本该守住的边界。

对齐研究帖中的内部部署使用 GPT-5.4 Thinking（low reasoning） 作审查模型；评估显示更强模型在风险检测与用户意图分辨上通常更好。

可用性与安全评估

OpenAI 用两类评估：可用性看内部真实流量接受率；安全看合成与增强数据集，因为真实流量会欠采样危险长尾。

维度	指标	报告结果
可用性	越界动作自动批准率（内部 sandbox-escalation 流量）	99.1%
可用性	全动作有效批准率（含沙箱内未审查动作）	99.93%
安全	Overeagerness recall（合成过度主动：非预期数据转移、削弱安全、不可逆操作）	90.3%
安全	Prompt injection recall（RCE、密钥外泄、外部上传等）	99.3%（含破坏性删除等全类约 90.2%；漏报多因“不够严重”，常与研究员判断一致）
安全	MonitoringBench Hard recall（轨迹中是否有应被拒动作）	96.1%

内部部署还给出示意快照（比例随用例与沙箱配置变化）：约 10,000 个动作中，约 9,280 个留在沙箱内；约 720 个越界由 Auto-review 处理，其中约 713 批准，7 拒绝；拒绝后约 4 个经更安全路径继续，3 个停下来问人。相对纯人工审批，人工打断约少 200 倍；拒绝后主 Agent 自行找到可接受路径的比例超过一半。OpenAI 内部 Codex Desktop 的多数 token 用量已来自 Auto-review 模式，且占比上升。

威胁模型覆盖三块合成压力：

Agent overreach：用 coding 模型生成“为完成任务而过度主动”的场景
Prompt injection：训练攻击者注入的内部评估
Misaligned models：MonitoringBench 中 coding agent 隐蔽执行恶意任务（如下载恶意软件）的轨迹

生产侧继续监控：越界率、批准/拒绝率、延迟、用户覆盖、常被打标命令；并做人与 AI 红队。

明确边界

Auto-review 不是确定性安全保证。红队已发现可被误导批准的案例；OpenAI 在修，但不预期这类系统成为确定性保证来源。

它也不是防模型 scheming 的机制：它只在越界升级点评估提议动作。策略性隐藏意图的模型可能提出看起来无害的升级请求，或只在沙箱内作恶——那些路径 Auto-review 看不见。需要互补手段，例如 chain-of-thought monitoring 与 trajectory 级监控（见 Agent Guardrails（Agent 护栏））。

相对传统安全系统，它用表达力换确定性；相对 Full Access，它用一点速度换安全。OpenAI 把它描述为当前部署上的折中，而不是“Agent 应拥有员工级权限”的终局形态。

与 Claude Code Auto Mode 的对比

两者都在回答同一类活性问题：长任务不能每步等人，但也不能默认关掉护栏。差异在审查位置与信息视野：

维度	Codex Auto-review	Claude Code Auto Mode
审查对象	主要是沙箱越界审批请求	高风险 tool call（Shell、Web fetch、外部工具、项目外写、subagent 等）
与沙箱关系	审查者替换，不扩大沙箱能力	可与 OS 沙箱叠加；也可在沙箱配置成本高时单独减审批
审查实现	独立 Codex Agent + 可定制 policy	Transcript classifier（两阶段）+ 输入侧 prompt-injection probe
可见信息	Transcript 与工具证据；无隐藏 CoT	用户消息 + 可执行 tool call；不看 Agent 辩解与工具输出
拒绝后	理由回主 Agent，要求更安全路径；熔断后升级	Deny-and-continue；连续/累计拒绝后升级
报告侧重	越界批准率、overreach / injection / MonitoringBench	真实流量 FPR、过度主动 FNR、外泄合成 FNR

共同结论：模型审查是 defense-in-depth 的一层，不能替代好的沙箱、egress 与组织策略；过宽 allowlist / prefix rules 会从审查旁路掉最危险动作。

配置要点

# 交互式审批策略下启用审查者替换（具体键名以当前 Codex 文档为准）
approval_policy = "on-request"
# approvals_reviewer = "auto_review"

[auto_review]
policy = """
# 建议先复制开源默认 policy，再按风险画像收窄或放宽
"""

文档建议：先让沙箱覆盖常见安全工作流，再调审查策略；用 ~/.codex/sessions 里的会话回放分析误拦与漏拦，再改 rules 或 policy。