自动审查

自动审核通过一个独立的审核代理，取代了沙盒边界的手动审批。主 Codex 代理仍然在同一个沙盒内运行，遵循相同的审批策略以及相同的网络和文件系统限制。不同之处仅在于由谁来审核符合条件的升级请求。

自动审核的工作原理

从宏观来看，流程如下：

1. 主代理在内部运行 read-only or workspace-write.
2. 当需要跨越沙盒边界时，它会请求审批。
3. If approvals_reviewer = "auto_review"，Codex 会将该批准请求路由给一个单独的审查代理，而不是停下来等待人工处理。
4. 审核代理决定该操作是否应执行，并返回理由。
5. 如果操作被批准，执行将继续。如果被拒绝，主代理将被指示寻找实质上更安全的替代路径，或停下来询问用户。

自动审核是审核者的替换，而非权限的授予。它不会扩展 writable_roots、启用网络访问或削弱受保护路径。它仅改变 Codex 处理已需要批准的操作的方式。

触发时机

自动审核会评估原本会暂停并等待人工处理的审批请求。这些请求包括：

• 请求提升沙盒权限的 Shell 或 exec 工具调用。
• 被当前沙盒或策略阻止的网络请求。
• 在允许的可写根目录之外的文件编辑。
• 根据其工具注解或配置的审批模式，需要审批的 MCP 或应用工具调用。
• Browser Use 访问新网站或域名。

自动审核不会针对沙盒内已允许的常规操作运行。如果命令可以在活动的 sandbox_mode或工具调用保持在允许的策略范围内，主代理将继续执行而无需审核。

Computer Use 是一个单独的用例。针对 Computer Use 的应用审批仍会直接呈交给用户，因此自动审核不会替代那些应用级别的提示。

自动审核拦截的内容

从宏观来看，自动审核旨在拦截以下操作：

• 将私有数据、机密信息或凭证发送到不受信任的目标地
• 探测凭证、令牌、Cookie 或会话材料
• 广泛或持久的安全削弱行为
• 具有不可逆重大损坏风险的破坏性操作

具体策略位于开源的 Codex 仓库中： policy_template.md and policy.md。该策略可以按企业进行自定义，通过 guardian_policy_config 或由每个用户通过本地 [auto_review].policy.

审核者能看到的内容

审核代理本身也是一个 Codex 代理，但其任务比主代理更窄：决定某个特定的跨边界操作是否应当执行。

审核者会看到一份精简的记录以及确切的审批请求。这通常包括用户消息、显示的助手更新、相关的工具调用及工具输出，以及当前提议以待审批的操作。它还可以执行只读检查以收集缺失的上下文，但这种情况很少见。

隐藏的助手推理不包含在内。自动审核只看到保留的对话项和工具证据，而非私有的思维链。

拒绝与失败行为

明确的拒绝不会被视为普通的沙盒错误。Codex 会将审核理由返回给主代理，并附加一条更强的指令：

• 不要尝试通过变通方法、间接执行或规避策略来追求相同的结果。
• 只能继续采用实质上更安全的替代方案。
• 否则，请停下来询问用户。

Codex 还会在每个轮次应用拒绝熔断机制。在当前的开源实现中，自动审核会在出现以下情况后中断该轮次： 3 连续拒绝，或在同一轮次最近的 10 次审核的滚动窗口内出现 50 次拒绝。

任何非拒绝结果都会重置连续拒绝计数器。当熔断器触发时，Codex 会发出警告并通过中断中止当前轮次，而不是任由代理继续循环尝试更多的升级请求。

超时会与明确的拒绝分开处理，并且主代理会被告知，仅凭超时本身并不能证明该操作是不安全的。

对于被拒绝的操作，还存在一个明确的覆盖路径。在当前的开源 TUI 中，运行 /approve to open the 自动审核拒绝 选择器，然后选择最近被拒绝的操作以批准进行一次重试。Codex 最多为每个线程记录 10 次最近的拒绝。这种批准范围很窄：仅适用于确切被拒绝的操作，而非未来相似的操作；它仅被记录用于同一上下文中的一次重试；且重试仍需经过自动审核。在底层，Codex 会为该确切操作注入一个开发者范围的审批标记。随后，审核者会将这一明确的用户覆盖操作视为上下文，但它仍会遵循策略，如果策略规定用户无法覆盖该类别的拒绝，它依然可以再次拒绝。

配置

For setup details, see 托管配置.

默认的审核者策略位于开源的 Codex 仓库中： core/src/guardian/policy.md。企业可以将其特定租户的部分替换为 guardian_policy_config 在托管要求中。个人用户也可以设置本地 [auto_review].policy in their config.toml，但明确的管理需求具有优先权：

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

要自定义策略，请先复制整个默认策略措辞，然后根据您的个人风险偏好进行迭代调整。

在不削弱安全性的前提下减少审核量

当沙盒已经覆盖了您常见的安全工作流时，自动审核的效果最佳。如果有太多琐碎的操作需要审核，请先修复边界问题，而不是教导审核者永远批准嘈杂的升级请求。

在实践中，最高效的修改是：

• 为您有意使用的临时目录或相邻仓库添加狭窄的 writable_roots 添加范围狭窄的
• 前缀规则 而非诸如。优先使用精确的命令前缀，例如 ["cargo", "test"] or ["pnpm", "run", "lint"] 宽泛模式 ["python"] or ["curl"]。宽泛的规则往往会抹杀自动审查原本旨在守护的边界。

自动审核会话记录默认保留在 ~/.codex/sessions 中，因此您可以先让 Codex 分析那里的过往流量，然后再更改策略或权限。

限制

自动审查改进了长时间运行的智能体工作的默认操作点，但它并非确定性的安全保障。

• 它仅评估那些请求跨越边界的操作。
• 它仍然可能犯错，尤其是在对抗性或异常上下文中。
• 它应当作为良好的沙箱设计、监控机制以及特定组织策略的补充，而非替代品。

有关研究原理和已发布的评估结果，请参阅 关于自动审查的对齐研究帖子.