自动审核使用独立的审核代理取代了沙盒边界处的人工审批。主要的 Codex 代理仍在同一个沙盒内运行，遵循相同的审批策略以及相同的网络和文件系统限制。不同之处在于由谁来审查符合条件的升级请求。
自动审核仅适用于交互式审批。实际上，这意味着 approval_policy = "on-request" 或仍会显示相关提示类别的细粒度审批策略。如果设置为 approval_policy = "never"，则无需进行任何审核。
自动审核的工作原理
从宏观层面来看，流程如下：
- 主代理在
read-only（只读）或workspace-write（工作区写入）模式下工作。 - 当需要跨越沙盒边界时，它会请求审批。
- 如果
approvals_reviewer = "auto_review"，Codex 会将该审批请求路由至独立的审核代理，而不是停下来等待人工处理。 - 审核代理决定是否执行该操作，并返回理由。
- 如果操作获得批准，执行将继续；如果被拒绝，主代理将被指示寻找更安全的路径，或停止并询问用户。
自动审核是审核者的替换，而非权限的授予。它不会扩展 writable_roots（可写根目录）、启用网络访问或削弱受保护路径。它只改变了 Codex 处理已需要审批的操作的方式。
触发时机
自动审核会评估那些本应暂停以等待人工处理的审批请求。这些包括：
- 请求升级沙盒权限的 Shell 或 exec 工具调用。
- 被当前沙盒或策略拦截的网络请求。
- 在允许的可写根目录之外的文件编辑。
- 根据工具注释或配置的审批模式需要审批的 MCP 或应用工具调用。
- 通过“浏览器使用”(Browser Use) 访问新网站或域名。
自动审核不会针对沙盒内已允许的常规操作运行。如果命令可以在活跃的 sandbox_mode 下运行，或者工具调用符合现有策略，主代理将无需审核直接继续执行。
“计算机使用”(Computer Use) 是一个特殊情况。针对“计算机使用”的应用审批仍会直接呈现给用户，因此自动审核不会取代这些应用级别的提示。
自动审核拦截的内容
总体而言，自动审核旨在拦截以下操作：
- 向不可信的目的地发送私人数据、机密或凭据
- 探测凭据、令牌、Cookie 或会话材料
- 广泛或持续的安全削弱行为
- 具有重大不可逆损害风险的破坏性操作
确切的策略位于开源 Codex 代码库中：policy_template.md 和 policy.md。该策略可以针对每个企业使用 guardian_policy_config 进行定制，或针对每个用户通过本地 [auto_review].policy 进行配置。
审核代理看到的内容
审核代理本身就是一个 Codex 代理，其工作比主代理更具体：决定是否应该运行特定的跨边界操作。
审核代理会查看压缩后的对话记录以及确切的审批请求。这通常包括用户消息、呈现的助手更新、相关的工具调用和工具输出，以及目前提议审批的操作。它偶尔也会执行只读检查以获取缺失的上下文，但这很少发生。
隐藏的助手推理过程不包含在内。自动审核查看的是保留的对话项和工具证据，而非私有的思维链 (chain-of-thought)。
拒绝与失败行为
明确的拒绝不会被视为普通的沙盒错误。Codex 会将审核理由返回给主代理，并添加更严格的指令：
- 不得通过变通方法、间接执行或规避策略来追求相同的结果。
- 仅在有实质性更安全的替代方案时才可继续。
- 否则，请停止并询问用户。
Codex 还会针对每次任务应用拒绝断路器。在当前的开源实现中，如果出现 3 次连续拒绝，或者在同一任务中最近 50 次审核的滚动窗口内出现 10 次拒绝，自动审核会中断该任务。
任何非拒绝操作都会重置连续拒绝计数器。当断路器跳闸时，Codex 会发出警告并以中断方式中止当前任务，而不是让代理陷入更多升级尝试的循环中。
超时会被单独处理，不同于明确的拒绝，主代理会被告知仅凭超时不足以证明操作是不安全的。
针对被拒绝的操作，还有一个明确的覆盖路径。在当前的开源 TUI 中，运行 /approve 以打开“自动审核拒绝”选择器，然后选择最近的一个拒绝操作进行单次重试批准。Codex 会为每个线程记录最多 10 次最近的拒绝。该批准范围很窄：它仅适用于确切的被拒操作，而不适用于类似的未来操作；它仅记录为单次重试；并且重试仍会经过自动审核。在底层，Codex 会为该确切操作注入一个开发者范围的批准标记。审核代理随后会将该显式用户覆盖视为上下文，但它仍会遵循策略，如果策略规定用户无法覆盖该类拒绝，它仍可再次拒绝。
配置
有关设置详情，请参阅 托管配置。
默认的审核策略位于开源 Codex 代码库中：core/src/guardian/policy.md。企业可以使用托管需求中的 guardian_policy_config 替换其租户特定的部分。个人用户也可以在他们的 config.toml 中设置本地 [auto_review].policy，但托管需求具有优先权。
[auto_review]
policy = """
YOUR POLICY GOES HERE
"""要自定义策略，请先复制完整的默认策略措辞，然后根据您的个人风险状况进行迭代。
在不削弱安全性的前提下减少审核量
当沙盒已经涵盖了您常见的安全工作流时，自动审核效果最佳。如果太多的平凡操作需要审核，请先修复边界，而不是教会审核代理永远批准嘈杂的升级请求。
实际上，杠杆率最高的变化是：
- 添加窄范围的
writable_roots（可写根目录），用于临时目录或您有意使用的邻近仓库。 - 添加范围狭窄的 前缀规则。优先使用精确的命令前缀（如
["cargo", "test"]或["pnpm", "run", "lint"]），而不是广泛的模式（如["python"]或["curl"]）。宽泛的规则往往会抹去自动审核旨在保护的边界。
默认情况下，自动审核的会话记录保存在 ~/.codex/sessions 下，因此您可以在更改策略或权限之前要求 Codex 分析那里的过去流量。
限制
自动审核改善了长时代理工作的默认运行状况，但它并非确定性的安全保证。
- 它仅评估请求跨越边界的操作。
- 它仍可能犯错，尤其是在对抗性或不寻常的上下文中。
- 它应该作为良好的沙盒设计、监控和组织特定策略的补充，而不是替代。
有关研究原理和发布的评估结果，请参阅 关于自动审核的对齐研究文章。