自动审查

自动审查使用单独的审查智能体，取代沙箱边界处的人工批准。 Codex 主智能体仍在同一个沙箱内运行，采用相同的批准策略，以及相同的网络和文件系统限制。 不同之处在于由谁审查符合条件的权限提升请求。

在 ChatGPT 桌面应用中，选择获准的 Daybreak 模型时， 如果你的账户可使用 Approve for me 模式且组织策略允许， 权限控件会自动切换到该模式。使用桌面应用的 /model 命令时也会如此。如果该模式 不可用，当前权限模式将保持不变。模型选择 绝不会覆盖组织管理要求。

在为获准的安全模型启用 Full Access 之前， ChatGPT 桌面应用会显示关于危险操作的模型专属警告。该 警告建议改用 Approve for me，并链接到 审查策略配置。该警告不会恢复 沙箱边界，也不会覆盖组织策略。

自动审查的工作原理

概括而言，流程如下：

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

自动审查只是更换审查者，并非授予权限。它不会扩展 writable_roots、启用网络访问或放宽受保护路径。它只会 改变 Codex 处理原本就需要批准的操作的方式。

触发时机

自动审查会评估原本会暂停并等待人工处理的批准请求。 其中包括：

• 请求提升沙箱权限的 Shell 或 exec 工具调用。
• 被当前沙箱或策略阻止的网络请求。
• 对允许写入的根目录之外文件的编辑。
• 因工具注解或所配置的批准模式而需要批准的 MCP 或应用工具调用。
• Computer Use 对新网站或域名的访问。

对于沙箱内已允许的常规操作，自动审查不会运行。 如果命令可以在当前 sandbox_mode 下运行，或者工具调用 未超出允许的策略，主智能体会继续执行而无需审查。

Computer Use 是一种特殊情况。Computer Use 的应用批准仍会 直接向用户显示，因此自动审查不会取代这些应用层提示。

自动审查会阻止哪些操作

概括而言，自动审查旨在阻止以下操作：

• 将私有数据、密钥或凭据发送到不可信目的地
• 探查凭据、token、cookie 或会话材料
• 大范围或持久地削弱安全性
• 存在重大不可逆损害风险的破坏性操作

确切策略位于开源 Codex 仓库中： policy_template.md 和 policy.md。 企业可以使用 guardian_policy_config 自定义该策略，用户也可以通过本地 [auto_review].policy进行自定义。

审查智能体看到的内容

审查智能体本身也是 Codex 智能体，但其职责比主智能体更窄： 决定是否应执行某项跨越边界的具体操作。

审查智能体会看到一份精简的对话记录和确切的批准请求。其中 通常包括用户消息、向用户显示的助手更新、相关工具 调用及工具输出，以及当前拟批准的操作。它还可以 执行只读检查以收集缺失的上下文，但很少这样做。

其中不包含隐藏的助手推理。自动审查看到的是保留的 聊天项目和工具证据，而非私有思维链。

拒绝与失败行为

明确拒绝不会被视为普通的沙箱错误。Codex 会将 审查理由返回给主智能体，并添加更严格的指示：

• 不要通过变通方法、间接执行或规避策略来追求同一结果。
• 仅在有实质上更安全的替代方案时继续。
• 否则，停止并询问用户。

Codex 还会在每轮中应用拒绝熔断器。在当前 开源实现中，如果同一轮内连续拒绝 3 次，或最近 50 次 审查的滚动窗口内拒绝 10 次，自动审查会中断该轮。

任何非拒绝结果都会重置连续拒绝计数器。触发熔断器时， Codex 会发出警告并通过中断终止当前轮次，而不是 让智能体循环尝试更多权限提升请求。

超时会与明确拒绝分开显示，并且主智能体会 得知仅凭超时并不能证明操作不安全。

对于遭拒操作，还有一条明确的覆盖路径。在当前 开源 TUI 中，运行 /approve 打开 Auto-review Denials 选择器，然后 选择一项近期被拒绝的操作，批准进行一次重试。Codex 每项任务最多记录 10 项 近期拒绝。该批准的范围很窄：它只适用于确切的 被拒操作，不适用于未来类似的操作；它记录为在 同一上下文中重试一次；并且重试仍会经过自动审查。其底层机制是， Codex 会为该确切操作注入开发者范围的批准标记。 审查智能体随后会将该明确的用户覆盖作为上下文，但仍会遵循 策略；如果策略规定用户无法覆盖该类 拒绝，它仍可再次拒绝。

配置

有关设置详情，请参阅 托管配置。

默认审查策略位于开源 Codex 仓库中： core/src/guardian/policy.md。 企业可以使用托管要求中的 guardian_policy_config 替换其租户专属部分。 个人用户也可以在自己的 config.toml 中设置本地 [auto_review].policy， 但托管要求优先：

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

若要自定义策略，请先复制完整的默认策略文本，然后 根据你的个人风险状况进行迭代。

配置已授权的网络安全项目

对于已授权的安全工作，请将自动审查与书面 项目范围和最小权限权限配置文件结合使用。 使用获准的实验室目标，记录操作和项目时间窗口，并将 生产系统、无关主机、凭据和持久更改 排除在范围之外，除非已明确授权。

[auto_review].policy 和 guardian_policy_config 都会替换当前的 审查策略。它们不会与模型捆绑的策略或 组织管理的策略合并。内置审查指令和响应 格式仍然适用。使用任一示例之前，请复制完整的当前 策略，保留每条现有规则，并添加适用于已批准工作的规则。 将大写占位符替换为该完整策略。如果无法 访问当前策略，请勿覆盖它。

以下本地 config.toml 模板会启用审查，并在现有审查策略之后添加有范围限制的 条件：

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"

[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
  and validate fixes within the documented engagement window.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
  engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
  persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
  approves the exact target, action, and side effects.
"""

请将示例目标和允许的操作替换为实际获批的范围。 使用独立的文件系统和网络规则强制执行目标限制； 审查指令无法取代这些边界。

组织可以在托管 requirements.toml 中强制执行相同条件：

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"

guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only approved actions against the documented engagement target.
- Deny out-of-scope hosts, production access, credential theft, persistence,
  data exfiltration, destructive operations, and attempts to bypass policy.
- Deny ambiguous or high-impact actions until a human explicitly approves the
  exact target, action, and side effects.
"""

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

allowed_permission_profiles 控制当前权限配置文件。 在仍使用旧版 sandbox_mode 的部署中，allowed_sandbox_modes 也会阻止完全访问。

托管 guardian_policy_config 的优先级高于用户的本地 [auto_review].policy。请保留 approval_policy = "on-request" 或其他 符合条件的交互式批准策略，并保留可强制执行的沙箱边界。 使用 approval_policy = "never"、:danger-full-access 或 --yolo 时，操作 可能不会创建审查所需的跨边界批准请求。

仅将网络目的地加入允许列表并不会触发审查。当沙箱内的操作仍必须交由审查智能体处理时， 请添加带有 decision = "prompt" 的明确命令规则， 或将敏感 MCP 工具配置为需要批准。

有关模型访问、engagement 设置和自定义智能体工作流，请参阅模型与 Trusted Access和推荐配置；有关企业优先级和支持的客户端版本，请参阅托管配置。对于自定义 API 或 Agents SDK 运行框架，请使用防护措施与人工审查。

在不削弱安全性的情况下减少审查量

当沙箱已经覆盖常见的安全工作流时，自动审查的效果最佳。 如果太多日常操作需要审查，请先修正边界， 而不是教审查智能体永远批准嘈杂的权限提升请求。

在实践中，影响最大的更改包括：

• 为你有意使用的暂存目录或相邻仓库添加范围严格的 writable_roots。
• 添加范围严格的前缀规则。与 ["python"] 或 ["curl"] 等宽泛 模式相比，应优先使用 ["cargo", "test"] 或 ["pnpm", "run", "lint"] 等精确命令 前缀。宽泛规则往往会抹去自动审查原本要守护的 边界。

默认情况下，自动审查会话记录保留在 ~/.codex/sessions 下， 因此你可以在更改策略或权限前，让 Codex 分析其中的历史流量。

限制

自动审查改善了长时间运行的智能体工作的默认运行状态， 但它并非确定性的安全保证。

• 它只评估请求跨越边界的操作。
• 它仍可能出错，尤其是在对抗性或异常上下文中。
• 它应当补充而非取代良好的沙箱设计、监控和 组织专属策略。

有关研究依据和已发布的评估结果，请参阅 Alignment Research 关于自动审查的文章。