OpenAI Codex 的 auto-review 解决的是“沙箱边界上的审批谁来做”这个问题：它不会放宽网络、文件系统或 writable_roots，只是把原本要人工确认的请求交给另一个 reviewer agent。只有在交互式审批启用时才生效，通常是 approval_policy = "on-request" 或仍会弹出相关提示的粒度策略；如果是 approval_policy = "never"，就没有可审的请求。
OpenAI Codex 自动审查与沙箱限制
OpenAI Codex 的 auto-review 用于在沙箱边界处替代人工批准。主 Codex agent 仍然运行在同一个 sandbox 中，使用相同的审批策略、网络限制和文件系统限制；变化的是，符合条件的升级请求由另一个 reviewer agent 来判断，而不是直接停下来等人确认。
auto-review 怎么工作
整体流程如下：
- 主 agent 在
read-only或workspace-write中工作。 - 当它需要跨越沙箱边界时，会请求 approval。
- 如果
approvals_reviewer = "auto_review"，Codex 会把这次审批请求路由给单独的 reviewer agent，而不是暂停等待人工。 - reviewer 决定这个动作是否应该执行，并返回理由。
- 如果批准，继续执行；如果拒绝，主 agent 会被要求寻找明显更安全的路径，或者停下来让用户处理。
auto-review 只是“reviewer swap”，不是“permission grant”。它不会扩大 writable_roots，不会开启 network access，也不会削弱受保护路径。它只改变 Codex 处理那些本来就需要 approval 的动作的方式。
什么时候会触发
auto-review 只会评估那些原本会让流程暂停给人的 approval request，常见包括：
- 需要提升 sandbox 权限的 shell 或 exec tool 调用
- 被当前 sandbox 或 policy 阻止的 network 请求
- 写入允许的 writable roots 之外的文件编辑
- 需要根据 tool 注解或配置的 approval mode 才能执行的 MCP 或 app tool 调用
- Browser Use 访问新 website 或新 domain
不会在沙箱内已经允许的日常动作上触发。只要命令可以在当前 sandbox_mode 下运行，或者某个 tool 调用仍然符合当前 policy，主 agent 就会继续执行，不会进入 review。
Computer Use 是单独的情况。Computer Use 的 app approvals 仍然会直接弹给用户，所以 auto-review 不会替代这些 app-level 提示。
auto-review 会拦截什么
从策略目标上看，auto-review 主要用于阻止这类动作：
- 把私密数据、secrets 或 credentials 发送到不受信任的目标
- 探测 credentials、tokens、cookies 或 session material
- 广泛或持续地降低安全性
- 具有明显不可逆损害风险的破坏性操作
具体策略定义在开源 Codex 仓库：
企业可以通过 guardian_policy_config 自定义租户级策略，个人用户也可以在本地 config.toml 中设置 [auto_review].policy，但 managed requirements 的优先级更高。
reviewer 能看到什么
reviewer 本身也是一个 Codex agent，但职责更窄：判断某个跨边界动作是否应该执行。
它看到的是压缩后的对话和精确的 approval request，通常包括：
- 用户消息
- 已展示的 assistant 更新
- 相关 tool 调用和 tool 输出
- 当前要审批的动作
它也可以偶尔做只读检查来补足上下文，但不会经常这样做。
隐藏的 assistant reasoning 不会包含在内。auto-review 看到的是保留的 conversation items 和 tool evidence，不是 private chain-of-thought。
拒绝和失败时会怎样
显式拒绝不等同于普通的 sandbox error。Codex 会把 review 理由返回给主 agent，并附加更强的指令：
- 不要通过 workaround、间接执行或 policy circumvention 去追求同一个结果
- 只允许继续尝试明显更安全的替代方案
- 否则就停下来询问用户
Codex 还会在每个 turn 上应用 rejection circuit breaker。按当前开源实现，Auto-review 会在同一个 turn 中出现以下情况时中断：
- 连续
3次拒绝 - 或在最近
50次 review 的滚动窗口里累计10次拒绝
任何非拒绝结果都会重置连续拒绝计数。触发 breaker 时，Codex 会发出 warning，并以 interrupt 方式终止当前 turn，而不是让 agent 继续循环发起升级请求。
timeout 会单独上报，不会被当成显式拒绝。主 agent 会被告知：仅凭 timeout 不能证明这个动作不安全。
还有一条针对被拒绝动作的显式覆盖路径。在当前开源 TUI 中，运行 /approve 会打开 Auto-review Denials 选择器，然后选择最近的一条被拒绝动作进行一次重试批准。Codex 会为每个 thread 记录最多 10 条最近拒绝。这个批准范围很窄：
- 只适用于那一个被拒绝的精确动作，不适用于类似的未来动作
- 只记录为同一上下文中的一次重试
- 重试仍然要经过 Auto-review
底层实现会为那个精确动作注入 developer-scoped approval marker。reviewer 会把这个显式用户覆盖作为上下文看到，但仍然会按 policy 判断；如果 policy 认为用户不能覆盖这一类拒绝，依然可以再次拒绝。
怎么配置
配置细节见 Managed configuration。
默认 reviewer policy 定义在开源 Codex 仓库的 core/src/guardian/policy.md。企业可以在 managed requirements 中用 guardian_policy_config 替换其中的租户专属部分；个人用户也可以在 config.toml 里设置本地 [auto_review].policy，但 managed requirements 优先级更高：
[auto_review]
policy = """
YOUR POLICY GOES HERE
"""自定义 policy 时，先完整复制默认 policy 的原文，再根据自己的风险模型逐步调整。
如何减少 review 次数而不削弱安全性
auto-review 最适合的状态是：sandbox 本身已经覆盖了常见的安全工作流。如果太多日常动作都需要 review，优先修边界，不要长期依赖 reviewer 去批准噪声很大的升级请求。
最有效的调整通常是：
- 为临时目录或你明确要用的邻近代码库，添加窄范围的
writable_roots - 添加范围尽量窄的 prefix rules
建议优先使用精确命令前缀，例如 ["cargo", "test"] 或 ["pnpm", "run", "lint"]，不要用过宽的模式，例如 ["python"] 或 ["curl"]。过宽的规则往往会抹掉 auto-review 原本要守住的边界。
默认情况下，auto-review 的 session transcript 会保存在 ~/.codex/sessions。在修改 policy 或 permissions 之前，你可以让 Codex 先分析那里过去的流量。
限制
auto-review 能改善长时间 agentic work 的默认运行点，但它不是确定性的安全保证。
- 它只会评估那些请求跨越边界的动作
- 在对抗性或异常上下文里，它仍然可能判断错误
- 它应该作为良好 sandbox 设计、监控和组织级 policy 的补充，而不是替代品
研究背景和评估结果见 Alignment Research post on Auto-review。
常见问题
OpenAI Codex 的 auto-review 会放宽沙箱权限吗
不会。auto-review 只是在“谁来审查审批请求”这一步换成 reviewer agent，不会扩大 writable_roots，也不会开启 network access，受保护路径规则也不会变。
哪些情况会触发 auto-review
会触发原本需要人工批准的请求，例如提升权限的 shell 或 exec 调用、被 sandbox 阻止的 network 请求、越过允许写入范围的文件编辑、需要审批的 MCP 或 app tool 调用，以及 Browser Use 访问新 website 或 domain。
approval_policy = "never" 时还能用 auto-review 吗
不能。approval_policy = "never" 表示没有交互式审批可审，auto-review 不会运行。