用 Claude Code 写完功能后，再让 Codex 审一遍，过去往往要退出当前工具、另开终端、重新交代项目状态。OpenAI 的 codex-plugin-cc 把本机 Codex 接进 Claude Code，可以直接做 review、委派任务，或把会话移交过去继续运行。
但两个 Agent 接入同一个项目，不等于自动形成协作。真正需要先分清的是四件事：运行环境谁共用，任务职责怎么分，谁有权修改文件，最后谁来批准结果。
先把插件放回正确位置
这个插件不是把 Codex 模型装进 Claude Code，也不是新的 IDE 或第三个独立 Agent。它通过本机已有的 Codex CLI 和 app server 执行任务，复用本地认证状态、配置和项目目录。
这会带来三个实际后果：
- Claude Code 和 Codex 可能使用同一份本地环境，Codex 中配置的模型、推理力度和 endpoint 可能继续生效；
- 两者可能看到同一个项目 checkout，一个后台任务修改文件时，另一个任务同时读取目录，就会产生竞态；
- 插件只负责接通入口，不替你决定任务该交给谁，也不替你承担审查责任。
更准确的比喻是：一张工作台上多了一个可以随时叫来的审查员和救火队员。
官方 README 给出的安装入口是：
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup
/codex:setup 会检查 Codex 是否安装并完成认证；缺少 CLI 时，如果 npm 可用，也会提供安装选项。
按任务性质分工
最容易犯的错不是输错命令，而是把所有事情都交给同一个 Agent。代码能写出来，和协作是否稳定，是两回事。
1. 连续修改多个文件：Claude Code 主导
需要不断看反馈、拆需求、落代码并继续修复的实现任务，适合由 Claude Code 主导。它保持当前会话上下文，更适合持续推进一条主线。
2. 需要第二个视角：Codex 审查
审查任务的重点不是让 Codex 重新实现一遍，而是围绕 diff、测试、边界条件和回归风险提出问题。
3. 长时间运行：再考虑委派
需要与当前对话解耦的工作，可以考虑委派，但前提是任务边界足够清楚。不要把一句“你看看还有什么问题”直接扔给后台。
可以把入口理解为：/codex:review 是一道审查门，/codex:exec 是一次明确的执行请求，委派则是把切好的任务交给另一个会话。命令只是入口，任务定义才是控制面。
Review Gate 不等于自动验收
/codex:review 返回的更像一份审查意见，里面可能有风险，也可能有需要补充的信息。真正容易循环的地方在后半段：Codex 提出问题，Claude Code 立刻修改，修改后又立即审查。
如果两个 Agent 都能直接动同一个 checkout，审查对象会不断变化，最后变成“修一个问题，再生一个问题”的往返。
更稳妥的分工是：
- Codex 只读当前 diff 并指出问题；
- Claude Code 决定哪些意见值得修改；
- 修改后运行相关测试；
- 测试通过，再由人决定是否合并。
每次 review 都应有停止条件：只检查当前 diff，只处理能复现的问题，修复后跑一次相关测试。没有停止条件的 review，很快会变成无休止的意见收集。
修改权限要按范围划分
如果确实需要 Codex 直接改文件，应先写清楚范围，例如只允许修改测试，或只修复 review 中列出的一个回归。范围越小，回滚和比较越容易。
长任务可以作为并行的第二条线，但不应默认成为主线。主线保持干净的工作目录，后台任务使用独立 checkout 或明确的只读审查范围，避免两个进程互相覆盖。
每次协作至少记录四项：
任务目标：
允许修改的范围：
审查要回答的问题：
最终由谁确认：
这张小卡片能让下一次打开会话时，仍然知道任务为什么停在那里。
适合谁，不适合谁
这套组合适合已经习惯看 diff、能运行测试，也愿意自己做最后判断的人。它可以减少工具切换，让第二个视角更容易进入当前工作流。
如果期待“装上插件后自动完成开发、自动修复、自动合并”，这套插件会让人失望。它解决的是调用入口，协作质量取决于任务边界、项目隔离和人的判断。
结论
Claude Code 写、Codex 查，是一种可行的分工方式。效果取决于三件事：审查是否作为独立环节，修改范围是否受限，每轮 review 是否有停止条件。
工具接通以后，责任不会自动消失。它只是让不同责任可以在同一个工作台上更快交接。