配置与权限：先只读，再考虑门禁

`codex-plugin-cc` 的配置可以分成三层。第一层是 Claude Code 插件层：`marketplace`、`install`、`reload-plugins` 决定命令是否出现在当前环境里。第二层是 Codex 可用性：Node.js 版本、`@openai/codex` 安装、ChatGPT 或 OpenAI API key 登录状态决定 `/codex:setup` 能否通过。第三层是工作流策略：你是只在需要时运行 `/codex:review`，还是开启 review gate，把 Codex 审查变成 Claude 停止前的强制钩子。 对于 API key 管理，README 只说明支持 OpenAI API key，没有在摘录里给出完整的 `.env.example`。实际操作时，原则是“密钥放在环境变量里，仓库里只保留占位示例”。下面这个块只作为本地环境示例，里面的值必须替换成你自己的占位符，或者由密钥管理系统注入，**千万不要把真实的 key 提交到 git**。 ```env OPENAI_API_KEY=replace_me CODEX_AUTH_MODE=demo CLAUDE_CODE_PLUGIN=codex@openai-codex CODEX_REVIEW_GATE=disabled ``` 这里需要讲清一个事实：补充材料没有给出 `codex-plugin-cc` 的正式 `.env.example`，也没有列出 `CODEX_AUTH_MODE`、`CLAUDE_CODE_PLUGIN` 或 `CODEX_REVIEW_GATE` 是插件真正读取的环境变量。它们不能当成项目官方的配置项来使用。来自 README 的、真正的配置动作是 `/codex:setup`、`/codex:setup --enable-review-gate`、`/codex:setup --disable-review-gate`，以及 `ChatGPT subscription` 或 `OpenAI API key` 这两种认证路径。上面那个 env 块的价值，只在于提醒团队建立本地密钥和策略占位的习惯，它并不等于插件的接口文档。 更稳妥的权限策略是先把 Codex 当作一个只读的 reviewer。README 明确写了 `/codex:review` 不会执行任何更改，这给了它进入日常开发的最低风险入口。开发者可以让 Claude Code 修改文件、运行测试、整理 diff，而 Codex 只负责只读检查当前工作，输出建议，由人来决定是否采纳。如果你确实需要让 Codex 承担任务委派，再逐步尝试 `/codex:rescue` 或 `/codex:transfer`，并记录每次任务的输入、输出和人工复核结果。 Review gate 则适合更谨慎地使用。它通过 Stop hook 拦截 Claude 的停止动作，本质上是在“Claude 认为任务完成”这个时间点，强行增加一次 Codex 审查。如果审查发现问题，Claude 需要先处理。这很适合高风险的变更前，作为一个局部的门禁，比如认证逻辑、迁移脚本、复杂重构、并发控制、支付相关代码或安全敏感的 diff。但它不适合在所有小改动上默认开启。小改动如果每次都触发一次漫长的 review，体验会被等待时间和额度消耗拖垮。

命令背后的工作流拆解

`/codex:review` 最合适的位置，是在“Claude Code 完成一轮改动之后，本地测试之前或之后”。如果你的仓库测试跑得很快，可以先跑测试再 review，让 Codex 看到一个至少能通过基本验证的 diff。如果测试很慢，可以先 review 设计和边界，再决定要不要补测试。README 中提到，多文件变更的代码审查可能需要更长时间，建议在后台运行，这是一个很实际的提醒：别把它当成即时的自动补全，而要把它当成一个异步的审查任务。 `/codex:adversarial-review` 更适合你心里有点没底的实现。比如，Claude Code 为了快速通过测试，写了一个复杂的条件分支，但你担心边界条件。或者重构时保留了旧接口的兼容逻辑，但没有证明不会破坏调用方。这时候，普通的 review 可能会围绕代码质量给建议，但 adversarial review 会直接挑战“为什么这个方案是安全的”。README 说它可以 `pressure-test assumptions、tradeoffs、failure modes`，并且允许在 flags 后面添加 `extra focus text`。这个设计比死板的固定模板有用得多，因为真实项目里的风险，通常不在语法，而在取舍。 `/codex:status` 和 `/codex:result` 决定了这个插件能不能进入更长、更复杂的任务流。很多 AI 编程工具的问题是，任务发出去以后状态不透明：你不知道它卡在读取上下文、运行推理还是等待外部命令。`codex-plugin-cc` 至少提供了查看 `running` 和 `recent Codex jobs` 的入口，并能展示 `finished job` 的 `stored output`。在可用时，还会包含 Codex session ID，方便你用 `codex resume` 回到那次 Codex run。这让它更像一个可管理的后台任务，而不是一次性的聊天回复。 项目自身的工程形态，在 `package.json` 里也能看到端倪。`scripts` 包含 `bump-version`、`check-version`、`prebuild`、`build` 和 `test`。`prebuild` 会创建 `plugins/codex/.generated/app-server-types`，并运行 `codex app-server generate-ts --out plugins/codex/.generated/app-server-types`。`build` 使用 `tsc -p tsconfig.app-server.json`。`test` 使用 `node --test tests/*.test.mjs`。这说明项目是一个 Node/TypeScript 插件形态，并且依赖 Codex app-server 的类型生成。对于准备贡献或审查源码的开发者来说，这些脚本比 stars 数更有用，因为它们清晰地说明了构建和测试的入口。 ```bash npm install -g @openai/codex npm run prebuild npm run build npm test ``` 这段命令更适合想看插件源码或参与贡献的开发者，不是普通用户安装插件的首选路径。普通用户走 Claude Code 插件市场就行。开发者如果要修改插件，才需要关注 `package.json` 里的 `prebuild`、`build`、`test`。这里的检查点也不同：普通用户检查 slash commands 是否出现；贡献者检查 TypeScript 编译是否通过、`node --test tests/*.test.mjs` 是否通过、生成目录是否符合预期。

一次可复用的审查任务怎么跑

要把 `codex-plugin-cc` 放进日常开发，建议从一个非常窄的流程开始：Claude Code 负责实现一个小任务，Codex 负责审查当前的 diff，人类只采纳可以验证的建议。一开始不要把它扩展成“Codex 自动改、Claude 自动合并、人类只看结果”。多 Agent 协作最容易出问题的地方不是模型不会写代码，而是输出责任不清：谁来改文件、谁来验证测试、谁来决定合并？ 一个可复用的试验流程可以这样设计。输入材料是一条明确的任务，比如“修复 CLI 参数为空时的错误提示，并补充测试”。Claude Code 先根据需求改文件，并运行仓库已有的测试。然后调用 `/codex:review`，让 Codex 只读检查当前工作。输出材料不是“Codex 的建议很好”，而是三类可处理项：**必须修的问题**、**建议补的测试**、**可以忽略但需要记录的取舍**。最后，由 Claude Code 或开发者自己修改，再跑一遍测试。 如果 Codex 的输出很长，先不要全盘照做。真正有价值的，是那些能被验证的建议：比如某个文件里的某个函数没有处理空输入，某个测试只覆盖了 happy path，某个错误分支吞掉了异常，某个类型收窄会影响调用方。不能验证的建议，只作为提示，不进入实际的 diff。这样做能避免“第二个 AI 的声音更大，所以就照着做”这种误区。 在更复杂一点的任务里，可以把 `/codex:adversarial-review` 放在合并前。比如，一个重构已经通过了测试，但你担心实现过度复杂。那就让 Codex 重点挑战设计：有没有更少文件变更的方案？是否引入了隐藏状态？是否让错误处理路径变得更难测试？Adversarial review 的价值在于制造摩擦。它不一定总是对的，但它能倒逼主 Agent 或开发者把取舍说清楚。 后台任务尤其适合多文件变更。README 提醒，多文件变更的 code review 可能需要一段时间，通常建议在后台运行。运行后用 `/codex:status` 检查进度，用 `/codex:result` 读取最终输出。如果发现审错了目标、base ref 选错了，或者等待时间过长，用 `/codex:cancel` 停止。这里的关键不是“有个取消按钮”，而是要真正把 AI 审查当作一个会失败、会跑偏、会消耗额度的任务来管理。

验收与失败边界

* **验收指标一：** 安装完成后，Claude Code 中应能看到 `codex` 相关的 slash commands，并且 `/agents` 中间出现 `codex:codex-rescue subagent`。如果命令不可见，先检查 `marketplace add`、`plugin install` 和 `/reload-plugins` 是否完整执行。 * **验收指标二：** `/codex:setup` 应返回 Codex 已安装并已认证。如果 Codex 缺失，按 README 用 `npm install -g @openai/codex`。如果未登录，用 `!codex login` 完成认证。 * **验收指标三：** 第一次 `/codex:review` 应针对当前工作区或分支 diff 给出具体审查意见，至少能落到文件、边界条件、测试缺口或替代实现上。如果输出只有泛泛的评价，说明输入范围或审查目标需要收窄。 * **权限与隐私边界：** `/codex:review` 在 README 中说明为只读且不会执行更改，但它仍然需要读取审查目标相关的上下文。敏感仓库、客户数据、密钥文件和未脱敏的日志，不应作为首次试用的材料。 * **成本边界：** README 明确写到使用会计入 Codex usage limits，review gate 还可能形成长时间的 Claude/Codex 循环。如果团队没有额度预算，或者没有取消任务的习惯，不适合默认开启 review gate。 * **失败条件一：** 如果 multi-file review 长时间没有结果，应该用 `/codex:status` 查看任务，并在目标选错或等待时间太长时，用 `/codex:cancel` 取消，而不是继续叠加新的审查任务。 * **失败条件二：** 如果 Codex review 多次提出无法复现、无法定位文件或与项目约束冲突的建议，说明当前仓库上下文、base ref 或提示焦点不适合扩大使用。这时应回退到人工审查，或者使用更小的 diff。 * **失败条件三：** 如果团队成员开始把 Codex 的输出当作合并的依据，而没有运行测试、检查 diff 和人工确认，那么插件反而会增加误合并的风险。AI 审查只能作为复核的输入，不能替代代码所有权。 验收时还要看输出形态。一个合格的 Codex review 不一定很长，但它应该能让开发者采取行动：补充哪条测试、修改哪个错误处理、确认哪个 API 兼容性、是否需要重新考虑实现方案。反过来，如果输出只是一些“建议增加日志”、“建议完善文档”这类没有上下文的通用建议，那就不算成功。对于 AI 编程工具，最小的闭环不是命令跑完了，而是建议进入了一个可验证的修复循环。

适合放进哪类开发环节

`codex-plugin-cc` 最自然的位置，是代码审查和 PR 前的自检。Claude Code 写完一轮代码后，开发者通常会看 git diff、跑测试、整理提交说明。把 `/codex:review` 插入这个环节，成本低、风险可控，因为它只读，不会直接改文件。它尤其适合多文件修改、测试补齐、错误处理、类型边界、迁移脚本和 API 兼容性检查。 第二个适合的位置，是调试失败任务后的复盘。Claude Code 修复一个 bug 后，最容易漏掉的是“为什么这个 bug 没被测试覆盖”。Codex 可以从 reviewer 的角度追问测试缺口：有没有回归测试？异常路径是否覆盖？输入为空、格式错误、权限不足时会怎样？这里需要的输出不是让它继续写代码，而是让它指出补测的方向。 第三个位置，是设计取舍前的挑战式复核。`/codex:adversarial-review` 的存在，说明项目作者也知道普通的 review 不够。很多实现不是错了，而是可能过度复杂、耦合过深，或者把问题转移到了未来。让 Codex 挑战当前的方案，能帮助开发者在合并前写清取舍：为什么不是更简单的实现？为什么不拆分 PR？为什么这个失败模式可以接受？ 不建议一开始就把这个插件放进自动合并、全仓扫描或强制门禁的环节。README 对 review gate 给出了明确的警告：它可能形成长时间的循环，并快速消耗 usage limits。这个警告比功能介绍本身更重要。任何会自动阻塞 Claude 停止动作的机制，都应该先在一个小仓库、小团队、小范围任务里试够了，再决定是否要扩大使用范围。

取舍判断

> **今天可以试的人：** 已经在 Claude Code 中处理真实代码改动、愿意用 Codex 做第二视角审查、并且能接受 ChatGPT/Codex 使用额度消耗的开发者。可以先在非敏感仓库里用 `/codex:review` 跑一个 2 到 5 个文件的 diff。 > **应该先观望的人：** 还没有 Claude Code 工作流、代码不能被外部 AI 工具读取、团队没有 API key 管理和额度预算，或者希望这个插件能直接替代人工 review 的团队。 > **试用时看三个指标：** 一看 `/codex:setup` 和 slash commands 是否稳定可用；二看 `/codex:review` 输出中有多少建议能落到具体文件、测试或错误处理；三看一次 multi-file review 的耗时和额度消耗是否能被日常开发接受。 > **下一步动作很明确：** 先安装插件，保持 review gate disabled，用只读 review 跑完一个小 diff。如果连续 10 到 20 次审查都能发现可验证的问题，再考虑把 `/codex:adversarial-review` 放进 PR 前自检，而不是直接启用自动门禁。 这件事短期真正值得试的点，是把 AI 编程从“一个 Agent 从头写到尾”的模式，改成“主 Agent 写，审查 Agent 挑错”的模式。它不会自动解决代码质量，也不会免掉人工判断，但它能把第二视角变成一个可随时调用的命令。对于已经使用 Claude Code 的开发者，这比再开一个终端、手动复制上下文要顺畅得多。对于还没有建立测试和审查习惯的团队，它只是更快地产生更多建议，并不一定会带来更好的结果。 最终判断可以更直接：`codex-plugin-cc` 不是给所有人准备的通用 IDE 插件，它更像是为 Claude Code 用户量身定做的 Codex 审查桥。先用 `/codex:review` 做只读复核，记录它发现的真实缺陷和误报。再用 `/codex:adversarial-review` 挑战复杂的改动。等你能稳定管理 `/codex:status`、`/codex:result` 和 `/codex:cancel` 之后，再讨论任务委派和 review gate。 读者看完以后能做的“最小动作”，就是在一个非敏感仓库里完成插件安装，跑一次 Codex 只读 review，把输出映射到测试或代码修改上，并记录这次审查是否真的减少了人工漏检。