codex-plugin-cc
人的天才只是火花，要想使它成熊熊火焰，哪就只有学习！学习。——高尔基
https://github.com/openai/codex-plugin-cc
当 Codex 住进 Claude Code：一次把代码评审、任务委托和长任务托管都交给它的优雅协作
在很多开发者的日常里，Claude Code 像一位坐在你身边、反应迅速、善于对话的搭档，适合一起梳理思路、现场改代码、讨论实现路径。而 Codex 更像另一位沉稳的工程师，擅长接过任务、独立推进、认真审视变更、在后台埋头干活，最后把结果端回来。
codex-plugin-cc 做的事情，就像给这两位搭档之间搭了一座门。你不用离开 Claude Code 当前的工作流，就能直接把 Codex 请进来，让它参与代码评审、挑战设计决策、接手问题排查，甚至把一段正在进行中的上下文平滑转交过去继续处理。
它不是一个花哨的中间层，也不是一套脱离日常习惯的新系统。它更像一个懂分寸的协调员：你继续在 Claude Code 里工作，它则负责把 Codex 安排到合适的位置，在你需要第二双眼睛、第二条思路、第二段执行力的时候，立刻补上那块拼图。
它到底是什么
codex-plugin-cc 是一个面向 Claude Code 用户的插件，核心目的非常直接：
让你在 Claude Code 里面直接使用 Codex，完成代码评审，或者把任务委托给 Codex 去处理。
仓库对它的描述也非常清晰：Use Codex from Claude Code to review code or delegate tasks.
换句话说，这不是“在 Codex 之外再造一个 Codex”，也不是“把 Claude Code 伪装成 Codex”。它的角色是连接，把两种工作方式连起来：
- 在 Claude Code 中发起 Codex 代码评审
- 在 Claude Code 中把任务委托给 Codex
- 在后台跟踪、查看、取消这些任务
- 把当前会话上下文迁移给 Codex，继续深挖
如果你已经习惯了 Claude Code 的节奏，这个插件最大的吸引力就在于：你不用换脑子，不用换场地，不用重新组织工作方式，直接在原来的工作流里把 Codex 拉进来。
它适合什么样的人
这个插件非常适合这样一类开发者：
你已经在用 Claude Code，并且你不想因为引入 Codex 而打断现有流程。
你可能有这些典型场景：
- 代码写完了，想让另一个模型做一次只读评审
- 不是只想找语法和细节问题，而是想让它挑战你的设计思路
- 遇到一个测试失败、CI 异常、可疑回归，想把调查任务完整委托出去
- 手头任务太长，不适合一直前台盯着，想让它去后台跑
- 已经在 Claude Code 里聊出了一大段上下文，不想从头再向 Codex 解释一遍
这时，codex-plugin-cc 就像一个非常能干的项目协调人。你一句话，它知道该叫 Codex 来审；你一句话，它知道该把任务递过去；你再一句话，它还能告诉你进度、拿回结果、甚至帮你把整个上下文平移过去。
它带来了什么
这个插件最实用的地方，是它提供了一组围绕真实开发动作设计的命令。
你得到的不是一个抽象能力，而是一套可以马上上手的工作入口：
/codex:review用于普通的只读代码评审/codex:adversarial-review用于更有攻击性、更能挑战实现方向的审查/codex:rescue用于把任务交给 Codex 子代理去调查、修复、延续/codex:transfer用于把当前 Claude Code 会话转成可继续的 Codex 线程/codex:status查看当前仓库里的运行中或最近任务/codex:result查看已完成任务的最终结果/codex:cancel取消活跃的后台任务/codex:setup检查 Codex 是否已安装、是否已认证，还能管理 review gate
如果把这些命令拟人化一点来看，这套插件像一位在团队里分工极其明确的同事：
review像严谨的评审工程师adversarial-review像总爱问“你确定这样最好吗”的架构挑刺专家rescue像临危受命的救火队员transfer像接班时能无缝读懂上下文的值班伙伴status像帮你盯看板的项目经理result像最后递交总结报告的执行者cancel像关键时刻会帮你踩刹车的人setup像入场前帮你整理装备的后勤负责人
使用它之前，你需要准备什么
它的要求并不复杂，但都很关键。
首先，你需要有以下其一：
- ChatGPT 订阅，包含 Free
- OpenAI API key
插件文档明确说明，使用这个插件会计入 Codex 的使用额度。
其次，你需要：
- Node.js 18.18 或更高版本
这两个条件像是入场门票。一个负责“你有资格调度 Codex”，一个负责“你的本地环境能把这件事跑起来”。
安装过程像把一位新同事请进工位
安装步骤不多，而且很顺。
先把 marketplace 加进 Claude Code：
1 | /plugin marketplace add openai/codex-plugin-cc |
然后安装插件：
1 | /plugin install codex@openai-codex |
接着重载插件：
1 | /reload-plugins |
最后运行初始化检查：
1 | /codex:setup |
这一套动作完成后，/codex:setup 会告诉你 Codex 是否已经准备就绪。
如果本地没有装 Codex，并且系统里有 npm，它甚至可以主动提出帮你安装。这个体验很像一位贴心的助手看了看你的桌面，然后说：工具还没放好，我可以顺手帮你装上。
如果你想手动安装 Codex，也可以直接执行：
1 | npm install -g @openai/codex |
如果已经安装了，但还没有登录，那么执行：
1 | !codex login |
当一切就绪后，你应该能看到两类东西出现在你的工作流里：
- 一组新的 slash commands
/agents里出现codex:codex-rescue这个 subagent
这意味着 Codex 不再是远远站在门外的另一个工具，而是真的已经穿好工牌，进了 Claude Code 的办公室。
最快上手方式
如果你只想快速感受它的节奏，README 给了一个非常好的首轮体验：
1 | /codex:review --background |
这三步特别像一次标准的协作闭环：
第一步，把评审任务交出去，而且放到后台跑。
第二步，过一会儿问一句，进展怎么样。
第三步，把结果拿回来。
没有复杂切换，没有额外上下文搬运，也没有“等我切到另一个工具里看看”。整个动作流畅得像你把一个任务递给隔壁同事，然后他处理完又把审阅意见发回到你桌上。
/codex:review：让 Codex 做一次标准而克制的代码评审
这是最基础、也是最常用的命令之一。
它会对你当前的工作做一次普通的 Codex review，质量上等同于你直接在 Codex 里运行 /review。
它适用于两类典型目标：
- 评审当前未提交的改动
- 对当前分支相对于某个基线分支进行评审，比如
main
最常见的命令可以这样写：
1 | /codex:review |
其中：
--base <ref>用于分支对比分支的评审--wait可以等待结果--background可以让它在后台跑
这个命令有一个很让人安心的特性：只读。
它不会改代码，不会偷偷替你执行修复动作。它的角色就是评审者，站在你代码旁边认真看、认真提意见，但不擅自伸手改动。
对于多文件改动，README 也明确提醒：评审可能会花一些时间，一般推荐放到后台执行。这个建议非常合理。因为多文件变更往往牵涉上下文、调用链、行为一致性，这种活儿就像请一位资深 reviewer 从头到尾看一遍，不可能只用眨眼的时间。
/codex:adversarial-review：它不是来附和你的，它是来挑战你的
如果说 /codex:review 是认真、客观、标准的审稿人，那么 /codex:adversarial-review 就像那位一坐下就会问你：
“这个方向真的对吗？”
“你为什么选这个设计？”
“这个权衡有没有更安全、更简单的替代方案？”
“这里会不会有 race condition？”
“这个实现是不是把复杂度藏起来了，而不是解决掉了？”
这就是它最有价值的地方。
它不是只看代码表面，而是会对实现方向和设计决策发起质疑。它适合在上线前、重构前、关键方案收口前使用，帮你做一次“压力测试式”的思维检查。
用法示例：
1 | /codex:adversarial-review |
和普通 review 一样，它支持：
--base <ref>--wait--background
但它比普通 review 多一个重要能力：可引导。
你可以在命令后面补充关注重点，让它把“挑刺火力”集中到某一个风险面上，比如：
- auth
- data loss
- rollback
- race conditions
- reliability
- hidden assumptions
- alternative approaches
它也依然是只读的，不负责修代码。它更像一位在发布会前专门负责唱反调的同事，而这位同事越专业，你越应该感谢他。
因为真正让系统稳健的，很多时候不是“没有人发现问题”，而是“有人在问题真的发生前就把难听的话说出来了”。
/codex:rescue：把问题交给 Codex，让它去查、去试、去救火
这是整个插件里最有“行动感”的命令之一。
/codex:rescue 会通过 codex:codex-rescue 这个 subagent，把任务交给 Codex 处理。
它适合以下场景：
- 调查一个 bug
- 尝试一个修复
- 延续之前的 Codex 任务
- 使用较小模型做更快或更便宜的一轮尝试
也就是说，它不再是点评员，而是接活的人。
你可以这样用：
1 | /codex:rescue investigate why the tests started failing |
这个命令支持：
--background--wait--resume--fresh
如果你没有指定 --resume 或 --fresh，插件还可以提出继续当前仓库里最近一次 rescue thread。这个设计很像一个记性很好的协作者，它知道你上次查到哪里了，也知道你这次更可能是想接着往下走，而不是一切重新开始。
它还有两个细节很值得注意：
第一，如果你不传 --model 或 --effort，Codex 会自己选默认值。
第二，如果你写的是 spark，插件会把它映射成 gpt-5.3-codex-spark。
甚至你不一定非得用命令式调用。README 还给了一个很自然的方式：
1 | Ask Codex to redesign the database connection to be more resilient. |
这非常像和队友说人话，而不是背一条生硬的控制指令。插件在这里扮演的角色，就是把自然语言意图递交给合适的执行者。
/codex:transfer：把当前对话无缝交接给 Codex
有些时候，你在 Claude Code 里已经聊了很久：
- bug 背景讲清楚了
- 现象确认了
- 可能原因排过一轮了
- 实现方向也讨论过了
这时如果再切去 Codex，从头解释一遍，往往很浪费。
/codex:transfer 的价值，就是把当前 Claude Code session 变成一个持久化的 Codex thread，并打印出一个可以继续使用的命令：
codex resume <session-id>
示例：
1 | /codex:transfer |
README 中提到，插件现有的 SessionStart hook 会自动提供当前 transcript 路径，--source 则是手动覆盖方式。
这项能力很像交接班时递过去的不只是工单标题，而是完整的值班记录、分析过程、上下文线索和未完成思路。Codex 接过去之后，不是“重新认识这个问题”，而是“从你们已经走到的位置继续向前”。
对于复杂调试、长链路排障、跨多轮实现讨论来说，这种上下文延续能力非常珍贵。
/codex:status：盯住后台任务，不靠猜
当你把 review 或 rescue 放到后台执行后，最怕的就是不知道它现在到底在干嘛。
/codex:status 就是这个时候的进度窗口。
示例：
1 | /codex:status |
它可以用来：
- 查看后台工作的进展
- 看最近完成的任务
- 确认某个任务是不是还在运行
它像一位不打扰执行者、但始终盯着任务状态的项目经理。你不需要频繁催促，也不必反复切换环境去看日志，只要一句 status，它就把最新情况递给你。
/codex:result：把最终结果拿回来
任务完成以后，你最关心的是结论。
/codex:result 用来展示已完成任务保存下来的最终输出。
示例：
1 | /codex:result |
当可用时，它还会带上 Codex session ID，这样你就可以直接在 Codex 里通过下面的方式重新打开那次运行：
1 | codex resume <session-id> |
这意味着结果不是一张静态纸条，而是一扇还能重新推开的门。你既可以在 Claude Code 里读结果，也可以回到 Codex 里继续审查、继续推进、继续深挖。
/codex:cancel：及时止损也是专业能力
后台任务不是每一次都必须跑到底。
有时你发现方向不对了，有时上下文已经变化了，有时任务本身不再值得继续消耗资源。
这时候，/codex:cancel 就派上用场：
1 | /codex:cancel |
它负责取消活跃的后台 Codex 任务。
这个命令的存在本身就很成熟。一个好工具不只是会启动、会执行、会交付，它也要会停。能及时踩刹车，往往比一路猛冲更重要。
/codex:setup：不仅是检查安装，它还能管理 review gate
很多人第一次看到 /codex:setup，可能会把它理解成一次性初始化命令。但实际上，它还肩负着一个更深的配置职责：管理可选的 review gate。
基础用途是检查：
- Codex 是否安装
- Codex 是否认证完成
如果缺少安装且 npm 可用，它可以帮你补装。
但除此之外，它还可以控制 review gate 的启停：
1 | /codex:setup --enable-review-gate |
当 review gate 启用后，插件会使用一个 Stop hook，根据 Claude 的响应触发一次有针对性的 Codex review。如果这次 review 发现了问题，停止动作会被拦住，于是 Claude 可以继续处理这些问题。
这个机制很像在出口前站了一位特别认真的质检员。你本来以为事情可以交付了，他看了一眼说：
“等等，这里还有问题，先别走。”
当然，README 也明确发出警告：review gate 可能会形成一个长时间运行的 Claude/Codex 循环，并且会更快消耗使用额度。因此它只适合在你准备主动监控会话时启用。
这很真实，也很诚实。它不是无脑推荐一个强功能，而是清楚告诉你：这位质检员很负责，但他也很费精力，别在你顾不过来的时候把他单独留岗。
几个非常顺手的典型流程
上线前做一次评审
这是最自然的用法：
1 | /codex:review |
它像上线前请资深同事扫一遍改动，看看有没有明显的问题、风险、疏漏。
把一个问题直接交给 Codex
例如 CI 构建失败：
1 | /codex:rescue investigate why the build is failing in CI |
这个动作的妙处在于，它不是“让模型给你几个猜测”，而是把调查任务本身交给它。
启动长任务，自己继续干别的
1 | /codex:adversarial-review --background |
然后再随时回来查看：
1 | /codex:status |
这特别像把一个比较耗时的工作分派给另一位同事，然后你自己继续做当前主线，不被打断节奏。
它底层是怎么接上 Codex 的
README 对这一点讲得很清楚：这个插件封装了 Codex app server，并使用你环境里全局安装的 codex 二进制，同时继承同一套 Codex 配置。
这意味着它不是另起炉灶，不是偷偷维护一套平行运行时，而是直接依托你本地已有的 Codex CLI 与 Codex app server。
这会带来几个非常重要的结果：
- 它使用你直接运行 Codex 时所使用的同一份安装
- 它使用同样的本地认证状态
- 它使用同一个仓库 checkout 和同一台机器上的本地环境
这几个点看似朴素，实际很关键。
因为一旦一个插件脱离了你的真实环境，很多协作就会变得不可信：看见的代码不一致、环境变量不一致、认证上下文不一致、配置不一致、行为复现不一致。
而 codex-plugin-cc 选择的是一条非常务实的路线：不假装拥有一套新世界，而是认真接入你已经在用的那个世界。
配置也能继承：你熟悉的 Codex 习惯不需要重来
如果你希望修改插件默认使用的模型，或者调整默认推理强度，可以在用户级或项目级 config.toml 中设置。
例如：
1 | model = "gpt-5.4-mini" |
配置的加载来源包括：
- 用户级配置
~/.codex/config.toml - 项目级覆盖
.codex/config.toml - 项目级覆盖仅在项目被信任时加载
这意味着如果你已经有一套 Codex 的使用习惯，比如偏好的模型、推理强度、某些端点配置，那么这个插件会尽量沿着你的旧路走，而不是逼你重新驯服一套新行为。
从体验上说，这很像一位新加入团队的同事，不要求你为了配合他改掉所有习惯，反而先努力适配你现有的工作方式。
还能直接把工作移交回 Codex
README 还提到，委托出去的任务，以及任何 stop gate 运行产生的工作，也都可以通过 codex resume 直接在 Codex 里恢复。
这就让整个协作链条变得很完整：
- 你可以在 Claude Code 中发起
- 你可以在 Claude Code 中跟踪
- 你可以在 Claude Code 中查看结果
- 你也可以随时把这条工作流切回 Codex 里继续
这不是单向桥，而是一座双向通行的桥。
对开发者来说，最舒服的工具通常不是“把你关在我的体系里”，而是“允许你在不同工作模式之间自然流动”。这一点上，codex-plugin-cc 做得很克制，也很聪明。
几个很实际的问题
我需要单独的 Codex 账号吗
如果你已经在这台机器上登录过 Codex，那这个账号通常就能直接在这里工作。因为插件使用的是你本地 Codex CLI 的认证状态。
如果你现在只用 Claude Code、还没用过 Codex，那么你还需要用 ChatGPT 账号或 API key 登录 Codex。
这点很重要：插件本身不是新的身份系统，它借用的是你本地已有的 Codex 登录体系。
它会不会用一套独立的 Codex 运行时
不会。
它就是通过本地 Codex CLI 和 Codex app server 来委托工作的。也正因为如此，它和你直接用 Codex 时所处的环境是一致的。
我现有的 API key 或 base URL 配置还能继续用吗
可以。
由于插件使用的是本地 Codex CLI，你当前的登录方式和配置都仍然有效。
如果你需要把内置 OpenAI provider 指向不同端点，可以在 Codex 配置中设置 openai_base_url。
这对已经有定制化环境、代理、网关或私有接入方式的团队来说，是一个非常实际的好消息。它没有要求你为了这个插件再把网络和认证体系重搭一遍。
为什么这个插件让人觉得顺手
很多工具介绍会喜欢强调功能数量，但 codex-plugin-cc 真正打动人的地方，不在于命令多，而在于命令和开发动作之间的关系非常自然。
你会发现它提供的不是抽象能力词，而是开发现场最真实的几个动作：
- 我想评审一下
- 我想有人来挑刺
- 我想把这个问题交出去
- 我想看看它现在做到哪了
- 我想拿结果
- 我想取消
- 我想把当前上下文迁过去继续
这些动作之间没有割裂感，像一个完整的协作闭环。而这个闭环又完全嵌在 Claude Code 的工作流里，不逼你跳出、不逼你重学、不逼你改习惯。
从产品气质上看，它有一种非常成熟的分寸感：
- 不装作自己是万能平台
- 不试图替代已有工具
- 不强迫你换工作方式
- 只在最需要的地方补上一层高价值连接
它更像一位懂协作的调度者，而不是一个爱抢戏的主角。
一个很生动的使用想象
你可以把它想成这样一个开发现场。
Claude Code 坐在你旁边，随时和你讨论问题、帮你修改、陪你推进。
Codex 则像办公室另一头那位极有经验的工程师，能做深度评审，也能独立领任务。
而 codex-plugin-cc 是那个把话传得到位、任务交得清楚、进度盯得明白、结果接得完整的协调人。
你对 Claude Code 说：
“帮我叫 Codex 来看看这次改动。”
于是它把 /codex:review 递过去。
你又说：
“这次不只是看代码，我想让它挑战一下这个设计是不是走对了。”
于是它把 /codex:adversarial-review 递过去。
你继续说：
“CI 炸了，我现在不想自己排，先交给它查。”
于是 /codex:rescue 出发了。
过一会儿你抬头问：
“它现在进行到哪了？”
/codex:status 回来了。
你再问：
“结论呢？”
/codex:result 把报告放到了桌上。
如果你想接过这份工作自己继续深挖，还可以直接 codex resume <session-id>。
这一整套体验，真正迷人的地方就在于：协作没有被工具切断，反而被工具变得更顺滑了。
结语
openai/codex-plugin-cc 不是那种靠概念取胜的项目，它的价值非常务实，也非常明确。
它把 Codex 带进 Claude Code，让代码评审、设计挑战、任务委托、后台执行、状态查看、结果回收、上下文迁移这些原本分散的动作，收拢成一条更顺手的工作流。
对于已经习惯 Claude Code 的开发者来说，它像给原本就高效的工作台添上了一位沉稳可靠的新搭档。你不需要离开熟悉的位置，就能在合适的时刻召唤 Codex，让它来审、来问、来查、来接手、来延续。
有些工具擅长炫耀自己能做多少事。
而有些工具真正厉害，是它知道自己应该在什么时候出现，并且一出现就把事情接得又稳又顺。
codex-plugin-cc 更像后者。
如果你已经在 Claude Code 里工作，又刚好希望把 Codex 的评审能力和执行能力自然接进来，这个插件很值得试一试。它不会喧宾夺主，但很可能会在你最忙、最赶、最需要第二双眼睛的时候，像一位靠谱同事那样，恰到好处地站到你身边。