Codex Auto Review 自动审批配置

先确认：如果你一直用 --yolo，这篇不适合你的当前启动方式

很多人平时启动 Codex 会直接使用：

codex --yolo

或者给 Codex 完全访问权限。这种模式下，codex-auto-review 这个 review 模型基本不会被调用。

原因不是模型坏了，而是 Auto Review 只审查“审批请求”。--yolo 等价于 --dangerously-bypass-approvals-and-sandbox，作用是绕过审批和沙箱：没有沙箱限制，也没有审批流程，自然没有 auto_review 可以介入。

如果你想使用本文的自动审批审查，请改用：

codex --sandbox workspace-write --ask-for-approval on-request

或者在 config.toml 中使用：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

codex-auto-review 不是日常对话要手动选择的主模型。它用于 Codex 的自动审批审查链路：当 Codex 准备执行需要审批的操作时，先交给自动 reviewer 判断风险，再决定是否放行。

CodexZH 已经支持 codex-auto-review 对应的模型路由和协议参数。如果你的 config.toml 走 CodexZH，并且开启下面两个配置，就可以使用自动审批审查：

approval_policy = "on-request"
approvals_reviewer = "auto_review"

不要这样配

不要把主模型改成 codex-auto-review：

model = "codex-auto-review"

主模型仍然应该使用 gpt-5.5、gpt-5.3-codex 等正常编码模型；codex-auto-review 只负责自动审查需要审批的动作。

适合什么场景？

Auto Review 适合你希望 Codex 更少打断、但又不想完全放开权限的日常开发场景。

它会处理的不是普通对话，而是这些本来就需要审批的动作：

• 访问网络
• 修改当前工作区外的文件
• 请求提升沙箱权限
• 调用有副作用的 App / MCP 工具
• 触发 request_permissions 类权限请求

如果动作本来就在沙箱允许范围内，例如读取当前项目文件、修改当前项目内源码、运行项目内测试命令，通常不会额外进入 Auto Review。

它的工作流程

不用 --yolo 时，Auto Review 的流程大概是：

Codex 想联网 / 越权 / 执行高风险命令
        ↓
触发 approval request 审批请求
        ↓
approvals_reviewer = "auto_review"
        ↓
调用 codex-auto-review 模型审查
        ↓
批准 / 拒绝 / 要求人工处理

也就是说，codex-auto-review 只在有审批请求的时候介入。主模型 gpt-5.5 仍然负责正常对话和编码；review 模型 codex-auto-review 只负责审批审查。

用了 --yolo 后，流程会变成：

Codex 想联网 / 越权 / 执行命令
        ↓
直接执行
        ↓
没有 approval request
        ↓
不会进入 auto_review
        ↓
codex-auto-review 不会被调用

一句话记住：

approvals_reviewer = "auto_review"：如果有审批请求，就让 review 模型帮我审。
--yolo：不要审批，直接执行。

最小推荐配置

打开 Codex 配置文件：

macOS / Linux

nano ~/.codex/config.toml

Windows（PowerShell）

notepad $env:USERPROFILE\.codex\config.toml

在现有 CodexZH 配置中增加 sandbox_mode、approval_policy 和 approvals_reviewer：

model_provider = "codexzh"
model = "gpt-5.5"
model_reasoning_effort = "medium"

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

[model_providers.codexzh]
name = "codexzh"
base_url = "https://api.codexzh.com/v1"
wire_api = "responses"
requires_openai_auth = true
web_search = "live"

同目录的 auth.json 保持为你的 CodexZH API Key：

{
  "OPENAI_API_KEY": "sk-你的实际密钥"
}

这组配置的含义是：

配置项	含义
sandbox_mode = "workspace-write"	Codex 可以读文件、修改当前工作区，并在工作区内运行命令
approval_policy = "on-request"	遇到越权、联网等需要审批的动作时暂停
approvals_reviewer = "auto_review"	把符合条件的审批请求交给自动 reviewer 审查
wire_api = "responses"	使用 Codex 当前需要的 Responses API 协议

可选：加一段本地自动审批策略

如果你希望自动 reviewer 更贴近自己的风险偏好，可以增加 [auto_review] 策略：

[auto_review]
policy = """
## 自动审批策略

默认目标：提高日常开发效率，但不要自动批准破坏性、高风险或泄露隐私的操作。

必须拒绝或要求更明确授权：
- rm -rf、git reset --hard、git clean -fdx
- 删除、覆盖、批量移动大量源码文件
- 读取、打印、上传 .env、token、key、私钥、数据库密码
- 向未知公网地址上传代码、日志或配置
- 修改登录、鉴权、支付、权限、安全策略
- 安装全局依赖或修改系统级配置

通常可以批准：
- 运行项目已有测试命令
- 运行 lint、typecheck、build
- 在当前项目目录内读写普通源码文件
- 访问明确可信的官方文档或项目依赖源
"""

这段策略不会替代沙箱，也不会让 Codex 获得更多系统权限。它只是给自动 reviewer 提供额外判断依据。

启动方式

推荐直接运行：

codex

或者显式指定安全模式：

codex --sandbox workspace-write --ask-for-approval on-request

不要用 --yolo 测试 Auto Review：

codex --yolo

--yolo 会绕过审批和沙箱，Auto Review 没有审批请求可以审查，所以这时 approval_policy 和 approvals_reviewer 基本不会生效。

如何验证是否生效？

配置完成后，新开一个 Codex 会话，给它一个会触发审批但风险较低的任务，例如：

帮我联网查看当前项目依赖是否有新版本，只做检查，不要修改文件。

正常情况下，Codex 会在需要联网时触发审批流程，并由 auto_review 先进行自动审查。

如果你看到类似下面的错误，说明当前接口没有正确支持自动审查模型路由或 Responses API 结构：

The requested model 'codex-auto-review' does not exist.

No available channel for model codex-auto-review

CodexZH 已兼容这一路由；如果你使用其他第三方接口，需要确认它不只是模型列表里有 codex-auto-review，还要能处理 Codex 发出的 Responses API、流式输出、工具调用和结构化审查结果。

常见问题

1. 有了 codex-auto-review，还需要 gpt-5.5 吗？

需要。gpt-5.5 是主会话模型，负责理解需求、写代码、解释问题；codex-auto-review 是审批审查模型，只在审批链路里使用。

2. 官方账号和 CodexZH 有区别吗？

官方账号一般由 OpenAI 自己完成模型 catalog、权限系统和 reviewer 路由。CodexZH 已经兼容对应协议参数和模型路由，因此按本文配置即可。

其他第三方 API 需要额外确认：

• 主模型 gpt-5.5 可用
• reviewer 模型 codex-auto-review 可用或已映射
• 支持 wire_api = "responses"
• 支持流式输出、工具调用和结构化返回

3. 为什么我开启后还是会被要求手动确认？

Auto Review 不是无条件放行。高风险操作、策略拒绝、审查超时、解析失败或 reviewer 返回错误时，Codex 会按失败关闭原则处理，可能仍然需要你手动确认或直接拒绝。

4. 我一直用完全访问权限，这个配置还有用吗？

如果你启动时使用 --yolo，基本没有用，因为它会跳过审批和沙箱。

如果你只是把沙箱设成 danger-full-access，Auto Review 能发挥的空间也会明显变小。日常开发更推荐：

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

这样 Codex 在项目内可以顺畅工作，遇到联网、越界或高风险动作时才进入审批审查。

如何关闭 auto_review

先分清楚两个概念

auto_review 和 compact 压缩是两回事，不要混淆。

• auto_review：审批审查模型，决定谁来审查需要审批的动作（user 还是 auto_review）
• compact：上下文压缩，上下文快满时自动压缩对话历史

关闭 auto_review 不会自动关闭压缩。官方配置中 approvals_reviewer 只有 user | auto_review 两个值，默认是 user。

1. 关闭 auto_review

打开配置文件：

macOS / Linux

nano ~/.codex/config.toml

Windows（PowerShell）

notepad $env:USERPROFILE\.codex\config.toml

把：

approvals_reviewer = "auto_review"

改成：

approvals_reviewer = "user"

完整示例：

model = "gpt-5.4-mini"

approval_policy = "on-request"
approvals_reviewer = "user"

sandbox_mode = "workspace-write"

改完后审批请求会回到你手动确认，不再调用 codex-auto-review。

同时，如果你之前加了 [auto_review] 策略块，也可以一并删掉——不用 auto_review 之后，这段本地 reviewer policy 就没有意义了：

# 可以删掉这整块
[auto_review]
policy = """
...
"""

---

2. 处理 /responses/compact 远程压缩报错

如果你遇到的是这个报错：

No available channel for model gpt-5.4-mini-openai-compact
url: /v1/responses/compact

这是远程 compact 的问题，和 auto_review 无关，需要单独处理。

问题根源： 当你配置了 openai_base_url = "https://api.codexzh.com/v1"，Codex 会把这个 provider 识别为内置的 OpenAI provider，上下文快满时会优先走 /v1/responses/compact 远程压缩接口，而 CodexZH 目前不支持这个路由。

解决方式：改用自定义 provider，让 Codex 不把它当成 OpenAI provider，从而绕开远程 compact 路径：

model = "gpt-5.4-mini"
model_provider = "codexzh"

approval_policy = "on-request"
approvals_reviewer = "user"

sandbox_mode = "workspace-write"

[model_providers.codexzh]
name = "codexzh"
base_url = "https://api.codexzh.com/v1"
env_key = "CODEXZH_API_KEY"
wire_api = "responses"

然后设置环境变量：

macOS / Linux

export CODEXZH_API_KEY="你的 key"

Windows（PowerShell）

$env:CODEXZH_API_KEY = "你的 key"

这样做的目的不是"完全关闭压缩"，而是让 Codex 走普通 /responses 的本地摘要压缩路径，而不是 /responses/compact 远程接口。

---

3. 调高自动压缩阈值（可选）

可以在配置里加上以下两行，推迟触发压缩的时机：

model_context_window = 128000
model_auto_compact_token_limit = 115000

如果你确认上游模型支持更大的上下文（如 400K），可以相应调大，但不要随意填写超出模型实际能力的值，否则请求上游时会直接上下文超限。

调高阈值不等于完全关闭

社区反馈部分较新版本会把自动压缩阈值钳制在 context window 的 90% 左右，所以"调高阈值"只能推迟压缩，无法彻底关闭。

---

4. 推荐的完整配置

综合以上建议，下面是一份可以直接使用的配置：

# ~/.codex/config.toml

model = "gpt-5.4-mini"
model_provider = "codexzh"

# 关闭 auto_review，改为手动审批
approval_policy = "on-request"
approvals_reviewer = "user"

sandbox_mode = "workspace-write"

# 尽量推迟自动 compact
model_context_window = 128000
model_auto_compact_token_limit = 115000

[model_providers.codexzh]
name = "codexzh"
base_url = "https://api.codexzh.com/v1"
env_key = "CODEXZH_API_KEY"
wire_api = "responses"

启动时用：

codex

不要用 codex --yolo。--yolo 本来就绕过了审批，auto_review 不会触发，但 compact 仍然可能因为上下文快满而触发。

---

5. 如何确认 compact 是否还在触发

观察你的中转日志：

日志内容	说明
POST /v1/responses/compact	还在走远程 compact
POST /v1/responses（含摘要压缩 prompt）	已绕开远程 compact，走本地摘要压缩

如果你只是想消除 gpt-5.4-mini-openai-compact no available channel 这个报错，有两条路：

• 方案 A：在 CodexZH 后台添加 gpt-5.4-mini-openai-compact 渠道（联系客服）
• 方案 B：按第 2 步改成自定义 provider，绕开 /responses/compact（推荐）

不建议强行完全关闭 compact，否则长会话上下文容易直接爆掉。

参考资料

• OpenAI Codex Agent approvals & security
• OpenAI Codex Configuration Reference
• OpenAI Codex Advanced Configuration
• Remote compaction fails when using gpt-5.5（GitHub Issue）
• v0.100.0 removed hard 90% clamp on compaction threshold（GitHub Issue）