自动审查

如需完整文档索引，请参阅 llms.txt。文档页面的 Markdown 版本可通过在页面后追加 .md 来获取 URL。

自动审查会在沙箱边界处用一个独立的审查 agent 取代手动批准。主 Codex agent 仍在同一个沙箱内运行，并受相同批准策略以及相同网络和文件系统限制约束。区别在于由谁审查符合条件的提权请求。

自动审查仅在批准是交互式时适用。实际上，这意味着 approval_policy = "on-request" 或仍会显示相关提示类别的细粒度批准策略。使用仍会显示相关提示类别。使用 approval_policy = "never"，就没有什么可审查的。

在 ChatGPT 桌面应用中，选择已批准的 Daybreak 模型会自动将权限控制切换为 为我批准 当该模式可用于你的账户且组织政策允许时。此规则也适用于你使用桌面应用的 /model 命令时。如果该模式不可用，当前权限模式将保持不变。模型选择绝不会覆盖组织托管要求。

在为已批准的安全模型启用 完全访问 之前， ChatGPT 桌面应用会显示一条针对该模型的危险操作警告。该警告建议改用 为我批准 并链接到审核者政策配置。该警告不会恢复沙箱边界，也不会覆盖组织政策。

自动审查的工作方式

整体流程如下：

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

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

触发时机

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

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

自动审查不会针对沙箱内已允许的常规操作运行。如果某个命令可以在当前 sandbox_mode下运行，或某个工具调用保持在允许的策略范围内，主 agent 会继续执行而无需审查。

Computer Use 是一个单独情况。Computer Use 的应用批准仍会直接呈现给用户，因此自动审查不会取代这些应用级提示。

自动审查会阻止的内容

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

将私人数据、机密信息或凭据发送到不受信任的目标
探查凭据、令牌、Cookie 或会话材料
大范围或持久性地削弱安全性
具有较高风险、可能造成不可逆损害的破坏性操作

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

审查代理看到的内容

审查者本身是一个 Codex agent，其职责比主 agent 更窄：判断某个特定的跨边界操作是否应该运行。

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

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

拒绝与失败行为

明确拒绝不会被当作普通沙箱错误处理。 Codex 会将审查理由返回给主 agent，并添加一条更强的指令：

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

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

任何非拒绝都会重置连续拒绝计数器。当断路器触发时， Codex 会发出警告，并以中断方式中止当前轮次，而不是让 agent 继续循环尝试更多提权。

超时会与明确拒绝分开呈现，主 agent 会被告知仅凭超时并不能证明该操作不安全。

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

配置

有关设置详情，请参阅 Managed configuration。

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

[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 控制当前权限配置文件。 allowed_sandbox_modes 还会在仍使用旧版 sandbox_mode的部署中阻止完全访问。

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

允许列表中的网络目标本身不会触发审核。添加显式命令规则并配合 decision = "prompt"，或将敏感 MCP 工具配置为需要批准，以便沙箱内的操作仍必须到达审核者。

请参阅模型和可信访问以及推荐的配置以了解模型访问、项目设置和自定义 Agent 工作流。请参阅托管配置以了解企业优先级和受支持的客户端版本。对于自定义 API 或 Agents SDK 运行框架，请使用 Guardrails 和人工审核。

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

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

实际上，最具杠杆效应的调整包括：

为你有意使用的暂存目录或相邻仓库添加狭窄的 writable_roots 。
添加窄范围的前缀规则。优先使用精确的命令前缀，例如 ["cargo", "test"] 或 ["pnpm", "run", "lint"] ，而不是宽泛的模式，例如 ["python"] 或 ["curl"]。宽泛规则往往会抹掉自动审查本应守护的边界。

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

限制

自动审查改善了长时间运行的 agentic 工作的默认运行状态，但它不是确定性的安全保证。

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

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