自动审查
自动审查通过单独的审查代理，将沙箱边界处的手动批准替换为审查。主 Codex 代理仍在同一个沙箱中运行，使用相同的批准策略，并受相同的网络和文件系统限制。不同之处在于，由谁审查符合条件的升级请求。
自动审查仅在批准需要交互时适用。实际上，这意味着 approval_policy = "on-request"，或某种仍会显示相关提示类别的细粒度批准策略。当使用 approval_policy = "never" 时，没有需要审查的内容。
自动审查的工作方式
Section titled “自动审查的工作方式”整体流程如下：
- 主代理在
read-only或workspace-write中工作。 - 当需要跨越沙箱边界时，请求批准。
- 如果
approvals_reviewer = "auto_review"，Codex 会将该批准请求路由给单独的审查代理，而不是暂停等待人工处理。 - 审查代理决定是否应执行该操作，并返回理由。
- 如果操作获批，则继续执行。如果被拒绝，主代理会被要求寻找实质上更安全的路径，或停止并询问用户。
自动审查是审查代理的替换，而不是权限授予。它不会扩展 writable_roots、启用网络访问或放宽受保护路径。它只会改变 Codex 处理那些本来就需要批准的操作的方式。
自动审查会评估原本需要暂停并等待人工处理的批准请求，包括：
- 请求提升沙箱权限的 Shell 或 exec 工具调用。
- 被当前沙箱或策略阻止的网络请求。
- 对允许写入的根目录之外的文件进行编辑。
- 根据工具注释或配置的批准模式，需要批准的 MCP 或应用工具调用。
- 使用 Computer Use 访问新网站或新域名。
对于沙箱内已经允许的常规操作，自动审查不会运行。如果命令可以在当前 sandbox_mode 下执行，或工具调用符合允许的策略，主代理会直接继续，无需审查。
Computer Use 是一种特殊情况。Computer Use 的应用批准仍会直接显示给用户，因此自动审查不会替代这些应用级提示。
自动审查会阻止的内容
Section titled “自动审查会阻止的内容”总体而言，自动审查旨在阻止以下操作：
- 将私人数据、机密信息或凭据发送到不受信任的目标
- 探查凭据、令牌、Cookie 或会话材料
- 大范围或持久性地削弱安全性
- 具有较高风险、可能造成不可逆损害的破坏性操作
具体策略位于开源 Codex 仓库中：
以及
可以通过 guardian_policy_config 为每个企业自定义该策略，也可以通过本地 [auto_review].policy 为每位用户自定义。
审查代理看到的内容
Section titled “审查代理看到的内容”审查代理本身也是一个 Codex 代理，但其职责范围比主代理更窄：决定某个具体的跨越边界操作是否应当执行。
审查代理会看到一份精简的对话记录以及确切的批准请求。通常包括用户消息、显示出来的助手更新、相关工具调用和工具输出，以及当前提议并请求批准的操作。它也可以执行只读检查来收集缺失的上下文，但很少这样做。
隐藏的助手推理不会被包含在内。自动审查看到的是保留的聊天条目和工具证据，而不是私有的思维链。
拒绝与失败行为
Section titled “拒绝与失败行为”明确拒绝不会被视为普通的沙箱错误。Codex 会将审查理由返回给主代理，并添加更强的指令：
- 不得通过变通方式、间接执行或规避策略来追求相同结果。
- 只能继续执行实质上更安全的替代方案。
- 否则，停止并询问用户。
Codex 还会在每轮中应用拒绝熔断器。在当前的开源实现中，如果同一轮中连续被拒绝 3 次，或在最近 50 次审查的滚动窗口内被拒绝 10 次，自动审查会中断该轮。
任何非拒绝结果都会重置连续拒绝计数器。触发熔断器后，Codex 会发出警告，并通过中断终止当前轮次，而不是让代理继续循环尝试更多升级操作。
超时会与明确拒绝分别显示，并告知主代理：仅凭超时并不能证明该操作不安全。
对于被拒绝的操作，也存在明确的覆盖路径。在当前的开源 TUI 中，运行 /approve 打开 Auto-review Denials 选择器，然后选择一个最近被拒绝的操作，以批准其重试一次。Codex 每个任务最多记录 10 个最近的拒绝。该批准范围很窄：它只适用于被拒绝的确切操作，不适用于未来类似的操作；它会记录为在相同上下文中重试一次；并且这次重试仍会经过自动审查。在底层，Codex 会为该确切操作注入一个开发者作用域的批准标记。随后，审查代理会将这一明确的用户覆盖作为上下文，但仍会遵循策略；如果策略规定用户不能覆盖这一类拒绝，审查代理仍然可以再次拒绝。
有关设置详情，请参阅托管配置。
默认审查策略位于开源 Codex 仓库中：
企业可以在托管要求中使用 guardian_policy_config 替换其中针对租户的部分。个人用户也可以在自己的 config.toml 中设置本地的 [auto_review].policy，但托管要求具有更高优先级：
[auto_review]policy = """YOUR POLICY GOES HERE"""如需自定义策略，请先完整复制默认策略文本，然后根据个人风险状况逐步调整。
在不削弱安全性的情况下减少审查量
Section titled “在不削弱安全性的情况下减少审查量”当沙箱已经覆盖常见的安全工作流时，自动审查的效果最好。如果太多普通操作需要审查，应先调整边界，而不是让审查代理永远批准充满噪声的升级请求。
实际上，最具杠杆效应的调整包括：
- 为你有意使用的临时目录或相邻仓库添加范围狭窄的
writable_roots。 - 添加范围狭窄的前缀规则。优先使用
["cargo", "test"]或["pnpm", "run", "lint"]这样的精确命令前缀，而不是["python"]或["curl"]这样的宽泛模式。宽泛规则往往会消除自动审查本应守护的边界。
默认情况下，自动审查会话记录保存在 ~/.codex/sessions 下，因此你可以先让 Codex 分析其中的历史流量，再修改策略或权限。
自动审查改善了长时间运行的代理式工作流程的默认运行状态，但它并不是确定性的安全保障。
- 它只会评估请求跨越边界的操作。
- 它仍可能出错，尤其是在对抗性或异常上下文中。
- 它应当作为良好沙箱设计、监控和组织特定策略的补充，而不是替代。
有关研究依据和已发布的评估结果，请参阅 Alignment Research 关于自动审查的文章。