OpenAI 做了个插件，让 Claude Code 干活 Codex 审查

大家好，我是若风。

2026 年 3 月，OpenAI 在 GitHub 上传了一个仓库，名字叫 codex-plugin-cc。cc 是 Claude Code 的缩写。

OpenAI 给自己的竞品 Anthropic 的 CLI 工具写了个官方插件，让 Claude Code 直接调用 Codex 来审查代码、委派任务。四个月后，27,836 个 Star。

这件事本身就很有意思。但你把它当八卦看就错过了重点。这个插件的技术架构，是到目前为止最成熟的「双 agent 协作」工程实现之一。

一句话定位

codex-plugin-cc 是一个 Claude Code 插件，通过 JSON-RPC over Unix socket 的 broker 架构，把 Codex 作为后台子进程嵌入 Claude Code 的工作流，实现代码审查、任务委派、会话转移。Apache 2.0 协议，JavaScript 实现。

不只是 slash 命令

很多人第一次看这个插件，以为它就是几个 slash 命令的封装。/codex:review 做代码审查，/codex:rescue 委派任务，/codex:transfer 转移会话。用起来确实就这么简单。

但翻进 plugins/codex/scripts/ 目录，你会发现一个完整的进程间通信架构。

核心文件是 app-server-broker.mjs。这个文件实现了一个 JSON-RPC broker，通过 Unix domain socket 做进程间通信。它的 main() 函数做了这些事。

• 用 net.createConnection() 连接到一个 Unix socket endpoint
• 维护一个 JSON-RPC 消息队列，支持流式方法(turn/start、review/start、thread/compact/start)
• 处理中断请求(turn/interrupt)
• 写 PID 文件做进程管理

这不是简单的 child_process.exec(),是一个真正的 RPC 服务架构。

broker 为什么要存在

Codex CLI 有一个 app-server 模式，它暴露了 JSON-RPC 接口让外部程序调用。Claude Code 的插件可以直接调 Codex CLI，为什么要中间加一层 broker？

答案在 lib/broker-lifecycle.mjs 里。

broker 解决了三个问题。

第一，进程生命周期管理。 createBrokerSessionDir() 用 mkdtempSync 创建临时目录，writePidFile() 写进程 PID。broker 有完整的启动、就绪检测、关闭流程。waitForBrokerEndpoint() 做轮询连接，每 50ms 试一次，直到 broker 的 socket 就绪或超时。

这意味着 Codex 进程不会因为 Claude Code 的某次操作失败而泄漏。broker 是一个独立的生命周期容器。

第二，会话隔离。 BROKER_STATE_FILE = "broker.json" 维护每个 broker session 的状态。不同的 Claude Code session 通过不同的 broker endpoint 隔离，不会互相干扰。issue #381 的标题就是「tear down brokers by sessionId on SessionEnd to avoid orphaned worktree brokers」，说明团队在认真处理 broker 泄漏问题。

第三，并发控制。 STREAMING_METHODS 定义了哪些 RPC 方法是流式的。流式方法需要长连接，非流式方法可以短连接。broker 做了连接复用，避免每次调 Codex 都启动一个新进程。

thin forwarding，这是关键设计

agents/codex-rescue.md 定义了一个 Claude Code subagent，叫 codex-rescue。这个 Agent 的设计文档里有一句话值得画重点。

「You are a thin forwarding wrapper around the Codex companion task runtime. Your only job is to forward the user’s rescue request to the Codex companion script. Do not do anything else.」

这是一个极薄转发层。它只做一件事，把用户的请求转发给 codex-companion.mjs 脚本，然后原样返回输出。文档列了一大堆「Do not」:

• Do not inspect the repository
• Do not read files
• Do not grep
• Do not monitor progress
• Do not poll status
• Do not summarize output

为什么不让它干任何事？因为如果 codex-rescue Agent 自己做了分析、读了代码、做了推理，它就消耗了 Claude Code 的 context window 和 token，而这些工作本来应该交给 Codex 做。thin forwarding 确保职责干净分离，Claude 做编排，Codex 做执行，两者不互相偷算力。

这个设计反映了双 Agent 协作的核心难题，谁来思考。如果两个 Agent 都思考，就浪费算力。如果两个都不思考，任务做不了。thin forwarding 选择了最极端的方案，一个只做编排不碰执行，另一个只做执行不管编排。

review gate 的 Hook 机制

prompts/stop-review-gate.md 是整个插件里最激进的设计。

它的原理是，当你启用 review gate 后（/codex:setup --enable-review-gate），插件注册一个 Claude Code 的 Stop hook。每次 Claude 准备停止输出（也就是回复完毕）之前，hook 会先跑一轮 Codex review，审查 Claude 这一轮做了什么代码变更。

review 的输出格式被严格约束。prompt 里有一个 compact_output_contract,要求第一行必须精确是 ALLOW: <reason> 或 BLOCK: <reason>。如果 Codex review 发现了问题，返回 BLOCK，Claude 的 Stop 被阻断，被迫继续修复。

这基本上实现了AI 审查 AI 的闭环。Claude 写代码，Codex 审查，发现问题打回去重写。

但 README 对这个功能有一个明确的警告，「The review gate can create a long-running Claude/Codex loop and may drain usage limits quickly. Only enable it when you plan to actively monitor the session」。

review gate 可能创建一个 Claude/Codex 之间的长时间循环，快速耗尽你的用量配额。OpenAI 自己也很清楚这个风险。这个功能适合那种「宁可慢也要对」的关键变更场景，不适合日常开发。

prompt 里的 grounding_rules 很有意思。「Do not treat the previous Claude response as proof that code changes happened; verify that from the repository state before you block」。Codex 不能只看 Claude 说了什么，必须从仓库的实际状态验证变更确实发生了。这防止了 Claude 声称做了修改但实际没做，Codex 盲目相信的情况。

两种 review 的区别

插件提供两种审查模式，这个区分很重要。

/codex:review 是 native review，只看代码细节，不可定制。它用 disable-model-invocation: true 禁止 Claude 在执行这个命令时自己推理，确保输出是 Codex 的原始审查结果。

/codex:adversarial-review 是 steerable review，可以挑战设计决策和架构方向。它接受额外的 focus text，比如 /codex:adversarial-review --base main challenge whether this was the right caching and retry design。它问的不是「这段代码有没有 bug」，而是「这个方案是不是对的」。

这两种模式的区分反映了一个真实的工程需求。代码审查有两个层面，tactical(战术层，代码质量)和 strategic(战略层，设计方向)。大多数审查工具只覆盖战术层。codex-plugin-cc 用两个独立命令覆盖了两层，adversarial-review 在发版前的压力测试场景尤其有用。

transfer 做了什么

/codex:transfer 是一个容易被忽略但很有价值的功能。它把当前 Claude Code 的会话上下文导入 Codex，生成一个 codex resume <session-id> 命令，让你在 Codex 里继续这个对话。

底层用的是 Codex 的 external-agent session importer。它把 Claude 的 JSONL 会话历史转换成 Codex 可识别的 session 格式，在 Codex App 或 TUI 里创建可见的对话轮次。

为什么需要这个？因为 Claude Code 和 Codex 各有擅长。Claude Code 擅长交互式编码、多文件协调、实时调试。Codex 擅长深度推理、大规模重构、独立执行。transfer 让你在两者之间无缝切换，而不是从头复述上下文。

Apache 2.0 和 OpenAI 的开放策略

codex-plugin-cc 的协议是 Apache 2.0,不是 OpenAI 之前常用的更严格的双条款协议。Apache 2.0 是最宽松的开源协议之一，允许商用、修改、分发，只要你保留版权声明。

这个选择不是偶然的。OpenAI 在 2026 年的策略明显转向了开放，开源 Codex CLI、Codex app-server，现在又给竞品的 CLI 写插件。背后的逻辑是，Codex 的护城河不在代码封闭，而在模型能力和用户基数。让 Codex 尽可能多地出现在开发者工作流里（哪怕是在 Claude Code 里），对 OpenAI 的战略价值大于封闭带来的收益。

你该不该用

说句实话，codex-plugin-cc 适合一种特定的开发者画像，同时订阅了 ChatGPT 和 Claude，且在两者之间切换成本高的人。

如果你只用 Claude Code，这个插件对你没用。如果你只用 Codex，同理。但如果你像我一样，日常用 Claude Code 做交互式编码，同时想用 Codex 做深度审查和独立任务委派，这个插件是目前最好的桥梁。

需要注意的坑是，它依赖你本地安装的 Codex CLI。/codex:setup 会检查 Codex 是否安装并认证，如果没装会提示你 npm install -g @openai/codex。它不是在云上调 Codex，是在你本机的同一个 Codex 实例上调。这意味着你的 Codex 用量配额会被消耗，免费额度很快会用完。

带走什么

拆完 codex-plugin-cc，我觉得最值得思考的是一个架构决策,什么时候该用 broker 中间层，而不是直连。

很多人做 Agent 集成的时候，第一反应是直接调 API。简单粗暴，A 调 B 的 HTTP 接口，拿到结果返回。但 codex-plugin-cc 选择了更重的方案，中间加一层 broker。

broker 的代价是复杂性，进程管理、socket 通信、生命周期管理，每一样都是额外代码。但收益是，两个 Agent 进程完全解耦，各自管理自己的资源，不会因为一方的崩溃污染另一方。这正是双 Agent 协作最需要的东西，隔离性。

当你需要集成两个长生命周期的进程（比如两个 AI Agent），且它们各自有复杂的状态和资源，中间加一层 broker 比直连更稳。这个判断在任何 IPC 场景都适用，不只是 AI Agent。

codex-plugin-cc 用 JSON-RPC over Unix socket 做这件事，但 broker 模式本身和具体协议无关。你用 gRPC、WebSocket、甚至消息队列，核心思路一样。关键是，让两个进程各自独立运行，通过一个中间人协调，而不是谁嵌在谁里面。