OpenAI 把 Codex 塞进 Claude Code：AI 编程工具开始互相寄生

7 月初，AI 编程工具圈冒出一个挺反常的东西：OpenAI 的 GitHub 账号下面，有一个专门面向 Claude Code 的公开仓库，叫 openai/codex-plugin-cc。

README 说得很直接：如果你已经在用 Claude Code，这个插件可以让你在原来的工作流里调用 Codex。OpenAI Developer Community 上也有介绍帖，提到几个使用场景：让 Codex 做一次普通 review，让它做一轮更挑刺的 adversarial review（对抗式审查），或者把卡住的任务交给 Codex 再跑一遍。

这件事有意思的地方，不是“又多了一个插件”。插件每天都有。

真正反常的是：OpenAI 没有要求开发者离开 Claude Code，再去自己的工具里使用 Codex。它反而把 Codex 塞进了 Claude Code 这个竞争对手的入口。

这说明 AI 编程工具的竞争，已经不只是“谁的模型更会写代码”。它开始变成一个更现实的问题：开发者每天站在哪个工作台前，别的 agent 能不能挤进这个工作台。

先把事实说清楚：它不是 Claude Code 内置 Codex

根据 openai/codex-plugin-cc 仓库 README 的描述，这个插件不是把 Codex 变成 Claude Code 的内置模型，也不是让 Anthropic 帮 OpenAI 托管 Codex。

更准确地说，它是一个 Claude Code 插件，包装用户本机已有的 Codex CLI / Codex app server，然后在 Claude Code 里暴露一组 slash command（斜杠命令）。README 给出的安装方式是：

1
2
3
4


/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

安装后，Claude Code 里会多出一组 /codex:* 命令。比如 /codex:review 做只读代码审查，/codex:adversarial-review 专门挑战实现思路，/codex:rescue 把一个卡住的问题交给 Codex 继续查，/codex:transfer 则把当前 Claude Code 会话转成 Codex 里可以继续的持久线程。后台任务相关的 /codex:status、/codex:result、/codex:cancel 也在同一套命令里。

这里要加一个边界：这些能力来自 OpenAI 这个插件自己的 README，不等于 Claude Code 原生就支持 Codex。它依赖用户本机的 Codex 安装、登录状态和配置。README 也写明，用户需要 ChatGPT 订阅或 OpenAI API key，还需要 Node.js 18.18 以上。

所以，这件事不能写成“Claude Code 支持 OpenAI 模型了”。更稳妥的说法是：OpenAI 正在利用 Claude Code 的插件和命令机制，把 Codex 做成一个可被 Claude Code 调用的外部执行者。

这个差别不小。

Claude Code 留出了入口，Codex 就能钻进来

这件事能发生，是因为 Claude Code 自己已经不只是一个聊天式 CLI。

Anthropic 的 Claude Code skills 文档里写得很清楚：skills 可以通过 SKILL.md 扩展 Claude 的能力，相关技能可以由 Claude 自动加载，也可以被用户直接用 /skill-name 调用。文档还说明，过去的 custom commands 已经并入 skills：.claude/commands/deploy.md 和 .claude/skills/deploy/SKILL.md 都可以创建 /deploy，只是后者能带更多支持文件和元数据。

也就是说，Claude Code 已经有了一套比较完整的扩展面。用户可以用 /review、/deploy、/codex:review 这种命令触发固定流程，不必每次把需求重新描述一遍；团队可以把发布检查、迁移流程、调试套路沉淀成 skill；插件则可以把命令、subagent（子智能体）、hook（钩子）和脚本打包进来。

Codex 插件吃到的正是这个扩展面。

它不是在说服用户“别用 Claude Code 了，来用 Codex”。它更像是承认了一个事实：很多开发者已经把 Claude Code 放进了终端、仓库和日常命令流。既然用户现在就站在这个入口前，那 Codex 最现实的办法不是把人拉走，而是先出现在这个入口里。

这比单纯发布一个 Codex 新功能更微妙。

入口抢不过来时，先变成入口里的按钮

如果按传统软件竞争逻辑看，OpenAI 这一步有点别扭。

OpenAI 和 Anthropic 都在抢 AI 编程入口。Claude Code 在终端里建立了很强的工作流黏性，Codex 也在强调自己的 CLI、app server、review 和 delegation（任务委派）能力。照理说，两个工具都应该把用户往自己的界面里拉。

但真实的开发者工作流没那么干净。

一个人打开仓库后，不是只问 AI “帮我写代码”。他可能先让工具读项目结构，然后改几个文件，跑测试，看报错，再让另一个模型帮忙审一遍；如果问题还没解决，就把任务丢到后台 agent 里跑。这里面没有一个环节天然属于某个厂商。

谁是主入口，往往取决于用户当时已经在哪里。

所以 OpenAI 把 Codex 放进 Claude Code，看起来像是在给竞品导流，但从分发角度看，它是在避免 Codex 被排除在 Claude Code 用户的工作流之外。抢不到桌面，就先放一个顺手的按钮在桌面上。

这不是投降。更像是寄生式分发。

Codex 为什么先做 review 和 rescue

从命令设计看，OpenAI 没有把 Codex 一上来定位成“替代 Claude Code 的主驾驶”。它挑了几个边界很清楚的位置。

最自然的是 review。

在 Claude Code 里，Claude 负责理解用户意图、推进修改、调用工具、维护上下文。等代码有了改动，再请 Codex 做第二视角。这比“同一个模型写完再自己审”更合理。代码审查本来就适合异构视角：另一个模型不共享前面的路径依赖，反而更容易问出一些刺耳但有用的问题。

/codex:adversarial-review 这个名字也很直白。它不是只看有没有语法问题，而是去挑战设计假设、风险区域和替代方案。对复杂改动来说，这类审查比普通 lint 更接近真实 reviewer 的价值。

rescue 也一样。当 Claude Code 卡住、测试失败、上下文变乱时，用户不一定想马上切换工具。他只是想要另一股力量介入。/codex:rescue 给的就是这个位置：不用重开一套工作流，先让 Codex 接一下。

/codex:transfer 则更像后手。它可以把当前 Claude Code 会话转成 Codex 里可继续的持久线程。也就是说，OpenAI 不只是想当一个审查插件。它也在给“把工作流接过去”留通道。

这一步很聪明：先做副驾驶，再做救援队，必要时再接管下一段路。

对 Anthropic 来说，开放扩展面会带来一点失控感

Claude Code 的插件和 skills 机制越好，生态当然越容易繁荣。个人可以沉淀自己的命令，团队可以共享流程，第三方工具也能接进来。

但入口一旦开放，就不可能只开放给友军。

OpenAI 可以进来，其他 coding agent（编程智能体）也可以进来。今天是 Codex 做 review，明天可能是 Gemini 做安全扫描，后天可能是某个开源 agent 做测试生成。只要插件机制足够顺手，竞争对手就会顺着扩展面进入。

这会让 Claude Code 越来越像一个开发工作流操作系统，而不是单一厂商的封闭工具。

操作系统的好处是生态，麻烦也是生态。用户会因为生态留下来，但生态里的关键任务未必都由平台方自己完成。浏览器就是这样：用户每天打开 Chrome，但密码管理、广告拦截、笔记、翻译、调试工具，很多都来自第三方。

对 Anthropic 来说，这未必是坏事。只要 Claude Code 仍然是入口，它就能获得更多用户时间和更强的默认位置。只是它必须接受一个现实：入口里的每个关键环节，不一定都由 Claude 完成。

当开发者习惯了“Claude 写，Codex 审，另一个 agent 跑测试”，单模型忠诚度就会下降。大家最后关心的是这条流水线稳不稳，少不少返工，而不是某个品牌是不是从头赢到尾。

竞争对象正在从产品变成运行时

过去一年，AI 编程工具的竞争常被写成产品榜单：Claude Code、Cursor、Codex、Devin、Qoder、OpenHands，谁更强，谁更便宜，谁更会修 bug。

但 Codex 插件这件事提示了另一个方向：竞争对象正在从“单个产品”变成“运行时”。

这里说的运行时，不只是模型。它包括读仓库、拿权限、跑命令、记录会话、管理后台任务、接回不同 agent 的结果，以及在危险操作前弹出确认。

Claude Code 的价值也不只是 Claude 模型。它已经有 CLI、文件系统访问、hook、skill、slash command、subagent、后台任务、权限提示和会话记录。开发者每天真正依赖的，往往是这一整套 agent runtime（智能体运行时），而不只是某次模型回答。

Claude Code 作为智能体运行时承载多 agent 协作

如果 Codex 插件能稳定工作，就说明别家的 agent 也可以复用这个 runtime 的一部分。

这会改变开发者选择工具的方式。问题不再只是“我应该用 Claude 还是 Codex”，而会变成“我的主工作台是谁，哪些任务交给哪个 agent”。

平台吃入口，插件吃场景。AI 编程工具正在往这个结构靠近。

国内开发者该看什么

对国内开发者来说，这件事不只是海外工具圈八卦。

第一层启发是，不要只盯模型榜单。模型强当然重要，但在真实开发里，效率往往卡在工作流编排上：谁来审代码，谁来跑测试，谁来修失败，谁来做发布前检查，谁来保留上下文。把这些串起来，比单点模型分数更接近生产力。

第二层启发是，多模型协作会变成常规动作。一个模型负责写，另一个模型负责审，一个便宜模型负责批量扫，一个强模型负责关键判断。这不是炫技，而是降低盲区。尤其在代码场景里，让同一个模型自写自审，本来就不太可靠。

第三层启发给企业内部平台：如果你只做一个聊天助手，很容易被更强模型替代；如果你做的是运行时，能把模型、工具、权限、审计、知识库和发布流程接起来，那就有机会成为团队真正离不开的入口。

所以 Codex 插件的价值，不在于“OpenAI 终于支持 Claude Code”。这个说法太轻了。

它更像是提前展示了一个方向：AI 编程工具之间不会长期保持纯粹互斥。它们会在用户工作流里互相嵌入、互相借道，有时还会互相接管任务。

竞争没有消失，只是换了形态。

结尾：谁在手边，谁就占便宜

这件事最后要回到一个很朴素的问题：开发者当时正在用什么。

Claude Code 的优势，是它已经被不少开发者放进终端、仓库和日常命令流里。它像一个工作台。Codex 插件的出现说明 OpenAI 至少承认了这一点：如果用户已经站在这个工作台前，Codex 就应该在那里出现。

但这也不代表 Claude Code 就稳了。平台一旦开放，里面的高价值环节就会被别人切走。今天 Codex 做 review，明天别的 agent 也可以做迁移、测试、安全扫描、性能分析。入口拥有流量，插件拥有专长，这两者会长期拉扯。

“互相寄生”听起来不太好听，但它可能正是 AI 编程工具成熟的标志。没有任何一个 agent 能独占所有任务。更高的效率，来自一个运行时把多个 agent 放到同一条工作流里，让它们在合适的位置上出现。

Claude Code 负责入口和执行上下文，Codex 负责某些审查、救援和接力场景。这个边界以后还会变，但关系已经变了。

下一轮 AI 编程工具竞争，可能不是谁把谁彻底打死，而是谁能成为其他工具不得不进入的那个工作台。

参考来源

以上来源用于核验插件安装方式、命令形态和公开叙事，不等同于对插件稳定性、使用量或长期产品战略的独立验证。