说白了，codex-plugin-cc 安装失败，90% 的情况不是插件本身坏了，而是三件事没做对：没有单独安装 codex CLI（导致 spawn codex ENOENT）、Node 版本低于 18.18、或者装完没有执行 /reload-plugins 让命令生效。把它当成一个“需要底层 codex CLI 支撑的遥控器”来理解，绝大多数报错就能一次定位——它自己不干活，真正执行的是本机的 codex。这也是为什么单独重装插件几乎没用。

说真的，这个插件第一次装就翻车了。openai/codex-plugin-cc 在 GitHub 上 star 涨得飞快，本周同时冲上日榜和周榜，可中文世界几乎搜不到一篇把报错讲清楚的。踩过一整轮坑之后，我们把 7 类高频报错整理成了这篇——从最经典的 spawn codex ENOENT，到 Windows 上返回空结果，再到 /codex:transfer 导入失败，全都是真实撞过的。

codex-plugin-cc 是什么？

codex-plugin-cc 是 OpenAI 官方发布的一款 Claude Code 插件，作用是让你在 Claude Code 的工作流里直接调用 Codex 来审查代码、发起对抗式评审，或把任务委托给 Codex 执行。它不是又一个聊天框，而是一座跨工具的桥：Claude Code 负责主流程，Codex 作为“第二双眼睛”在后台跑评审或救火。

它的核心命令包括 /codex:review（评审未提交改动）、/codex:adversarial-review（对抗式评审，专挑设计缺陷）、/codex:rescue（把一个 bug 或调查任务甩给 Codex）、/codex:transfer（把当前 Claude 会话导出成 Codex 线程）。

前置条件：装之前先对表

大部分“安装失败”其实倒在前置条件上。开工前先核对这张表：

标准安装四步（在 Claude Code 里依次输入）：

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

注意最后一步 /codex:setup 会做就绪检查，也能开关“评审门（review gate）”——这个开关后面会专门提醒。

90% 的“安装失败”其实不是插件的问题

这是踩完坑后最想说的一句反常识判断：多数人报“装不上”，根因根本不在插件。按 GitHub Issues 的分布看，最高频的失败集中在三处——codex CLI 没装、Node 版本太低、装完没 reload。插件本身只是几百 KB 的命令封装，它不下载模型、不跑推理，真正执行的是你本机的 codex 进程。所以当命令报错时，第一反应不该是“重装插件”，而是“底层的 codex 通不通”。

报错 1：spawn codex ENOENT

这是出镜率最高的报错，含义是系统找不到 codex 这个可执行文件。

原因：你只装了 Claude Code 插件，但没有全局安装 codex CLI，或者装了但不在 PATH 里。

解法：

npm install -g @openai/codex
codex --version  # 能打印版本号就说明 PATH 通了

报错 2：Node 版本过低导致安装失败

原因：codex-plugin-cc 要求 Node.js ≥ 18.18，低于这个版本安装或运行时会报语法/依赖错误。

解法：先 node -v 查版本，低于 18.18 就用 nvm 升级：

nvm install 18.18
nvm use 18.18

升级后重新执行安装四步。

报错 3：codex login 没登录，命令跑不动

原因：codex CLI 装好了，但没有完成账号认证，评审/救火命令会在调用模型时卡住或报权限错。

解法：在终端执行登录（免费档 ChatGPT 账号也可用）：

codex login

登录成功后回到 Claude Code 重试命令即可。

报错 4：命令不出现 / 装完不生效

原因：/plugin install 之后没有执行 /reload-plugins，Claude Code 还没加载新命令；命令列表里自然搜不到 /codex:*。

解法：手动执行 /reload-plugins，再运行 /codex:setup 做就绪检查。若个别命令仍隐藏，注意部分版本命令带 disable-model-invocation 标记，只能由用户手动触发、不能被模型自动调用——这是设计行为，不是 bug。

报错 5（Windows）：/codex:review、/codex:rescue 返回空结果或只读报错

Windows 是这个插件当前的重灾区。典型表现是评审命令返回空、/codex:rescue 报 read-only sandbox error、或卡在 "Initializing…"。

原因：Windows 下沙箱模式与命令执行策略存在兼容问题（Issues 里多条相关记录，涉及 PowerShell/Git Bash 环境）。

临时解法：

• 优先在 WSL（Linux 子系统）里运行，绕开原生 Windows 沙箱；
• 多文件评审改用后台模式，避免长时间阻塞；
• 关注插件更新，这类问题修复节奏较快。

报错 6：/codex:transfer 报 "did not record an imported thread"

原因：会话导入失败，通常是两点——Codex 版本过旧，不支持会话导入；或 --source 指定的路径不在 ~/.claude/projects 目录下。

解法：

npm update -g @openai/codex  # 升级到支持会话导入的版本

并确认 --source 路径位于 ~/.claude/projects 之下。

报错 7：后台任务一直卡 "running" / 静默死亡

原因：后台 job 的进程（broker、app-server）在回合中途被杀，或并发写入 state.json 缺少锁导致状态丢失，任务就永远停在 running。

解法：用 /codex:status 查状态、/codex:cancel 取消卡住的任务后重发；非英文 Windows 环境下 /codex:cancel 本身也可能报错，此时手动结束终端里的 codex 进程更稳妥。

⚠️ 一个容易忽视的坑：评审门会烧额度

/codex:setup 里的“评审门（review gate）”开启后，会在每次改动时自动触发 Codex 评审。官方明确警告：它可能造成 Claude 与 Codex 之间的长循环，快速消耗用量额度。除非你在旁边盯着，否则别常开——建议默认关闭，需要时再手动跑 /codex:review。

多模型协作评审确实会显著抬高推理调用量，需要合理规划成本与额度。

7 类报错速查表

FAQ

Q1：codex-plugin-cc 收费吗？免费档能用吗？
插件本身免费。它调用的 Codex 需要 ChatGPT 订阅（含免费档）或 OpenAI API Key，免费档账号登录后即可试用，但用量有限。

Q2：装了这个插件，还用得上 Claude Code 原生审查吗？（争议题）
有人说装了 codex-plugin-cc 就能替代 Claude Code 自己的审查，也有人说纯属多此一举、徒增额度消耗。从实际使用来看，两者不是替代关系，而是“交叉验证”——让 Codex 做对抗式评审去挑 Claude 方案的毛病，价值在于视角差异，而不是谁比谁强。但如果你只是写小脚本，确实没必要开双份评审。

Q3：Windows 到底能不能用？
能装，但当前 Windows 原生环境报错较多（沙箱、Git Bash 的 taskkill）。稳妥做法是在 WSL 里跑。

Q4：/codex:adversarial-review 报错怎么办？
部分版本在默认模型下会失败，可显式指定较稳定的模型版本重试；同时确认 codex CLI 已是最新版。

Q5：会话导入的 --source 路径有什么限制？
必须位于 ~/.claude/projects 目录下，否则会报 "did not record an imported thread"。

总结

codex-plugin-cc 的安装失败，几乎都能归到 7 类里：codex CLI 缺失、Node 版本过低、未登录、未 reload、Windows 沙箱、transfer 路径/版本、后台任务卡死。据 OpenAI 官方 README 与 GitHub Issues 的现有记录，其中 Windows 相关问题占比最高、修复也最活跃。本文基于 2026 年 7 月的插件版本与 Issues 实测整理，插件迭代较快，部分命令行为和报错可能随版本变化，请以官方最新文档为准。

有一个问题到现在也还没完全想清楚：当“让一个 AI 去审另一个 AI 的代码”变成标配后，到底是在提升代码质量，还是只是把 review 这件事的责任又往后推了一层？实际用对抗式评审跑了一阵，确实抓到过 Claude 漏掉的边界条件，但也有几次两个模型在一个错误方向上互相点头。如果你也在用双模型交叉评审，很想听听你遇到的是“1+1>2”，还是“两个都不靠谱”——评论区聊聊。

参考资料

• codex-plugin-cc 官方仓库（OpenAI）：https://github.com/openai/codex-plugin-cc