最近这两周社区里讨论度最高的编程工具话题已经从Claude Code 真香慢慢变成了Claude Code 和 Codex 到底该留哪个。我自己在 Claude Code 里攒了大半年的插件、一套顺手的斜杠命令、还有几个给自己项目定制的 agent看到 Codex 风头正劲的时候第一反应也是去装一个试试。结果一上手就发现插件这套东西在两边根本不是同一个玩法。你没法把~/.claude/plugins整个拷到~/.codex里就完事选插件的标准、配置的写法、记忆文件的组织方式全都要重新捋一遍。这篇文章就围绕我实际踩过的路来聊Claude Code 插件到底怎么选以及从 Claude Code 迁移到 Codex 时真正要处理的那些细节。适合那些已经在用 Claude Code、手里攒了不少插件又想尝试 Codex 的开发者也适合刚接触这两套工具、想知道插件生态差在哪里的新手朋友。1. 插件生态的底层差异Claude Code 和 Codex 根本不是同一套玩法很多人在迁移前没意识到一个问题Claude Code 的插件是一套完整的扩展运行时而 Codex 的插件更像是配置文件拼出来的组合技。两者名字都叫扩展底层的设计哲学差得很远。1.1 Claude Code 插件的真实构成不只是斜杠命令Claude Code 的插件目录一般被大家理解成装一堆 slash command 的地方其实一个完整插件的构成比这复杂。我拆开看过不少社区插件标准结构里至少包含这几类东西Slash Commands/xxx这种斜杠命令本质是预设的 prompt 模板加参数处理逻辑。Agents子代理定义自带 system prompt 和工具集可以实现一些半自动化的独立任务流。MCP Servers通过 MCP 协议接入外部工具和数据的服务器配置比如接数据库、接浏览器、接内部 API。Hooks事件钩子能在特定事件比如文件写入前、命令执行前插入自定义脚本这是插件里权限最大也最容易出问题的部分。这几个部分被写进插件的元数据文件plugin.json里插件管理器启动时会读取它然后按照里面的定义去注册命令、挂载 hook、启动 MCP 连接。社区里最常用的插件市场是 dsh plugin 那一套安装指令类似dsh plugin --profile web add dshmarket装好之后通过dsh plugin list可以查看当前已装的插件树。这个插件树就是所有已启用插件的加载关系任何一个节点出问题都会报出类似dsh: plugin tree failed to load: failed to apply loader entry include的错误后面我会专门讲这个坑。1.2 Codex 的扩展思路配置驱动插件化程度完全不同再看 Codex 这边。OpenAI Codex CLI 的设计明显更克制它没有一套完整的插件运行时取而代之的是几个配置驱动的扩展点AGENTS.md项目级记忆文件相当于 Claude Code 里 CLAUDE.md 的角色但它更像是给模型看的说明书而不是插件注册中心。~/.codex/config.toml全局配置可以定义模型供应商、模型名称、MCP server、环境变量等。~/.codex/prompts/自定义指令目录你可以把一些常用的提示词模板放在里面通过/xxx类似的命令引用但这只是轻量级的 prompt 预置没有执行逻辑。MCP ServersCodex 也支持 MCP但配置格式和 Claude Code 完全不同Claude 是 JSONCodex 是 TOML。扩展维度Claude CodeCodex命令行扩展Slash Commands可带参数和逻辑prompts 目录纯 prompt 模板子代理Agents独立工具集无直接等价物外部工具MCP ServersJSON 配置MCP ServersTOML 配置事件钩子Hooks可执行脚本无等价物加载方式插件树 / 市场安装配置文件直接读取所以你看真正能无损平移的只有一部分纯 MCP 类型的插件。其余带 hooks、带 agent 逻辑的插件迁移到 Codex 时就得想办法用别的机制去替代。2. 选插件时我在看什么四个比功能列表更重要的维度我最初挑插件的时候也犯过哪个看起来功能强就装哪个的毛病后来插件一多CLI 启动直接变慢偶尔还会互相冲突才意识到选插件这件事不能只看功能列表。现在我在决定要不要装一个插件之前会先过四个维度。2.1 维护活跃度一个插件三个月没更新等于定时炸弹CLI 工具版本的迭代速度是很快的Claude Code 和 Codex 都在频繁更新。插件如果是那种三个月以上没有 commit、issue 区堆满未回复的状态我基本直接劝退。因为只要 CLI 有一次破坏性更新这种插件就会第一个崩而且没人会修。判断方法很简单去插件仓库看最近一次提交时间、看 issue 的响应速度。star 数量只能代表它曾经火过不代表现在还活着。我遇到过几个 star 很高但已经没人在维护的插件装完之后只能自己 fork 改代码非常被动。2.2 权限边界与数据流向插件到底碰了哪些不该碰的东西Claude Code 有比较细的权限控制机制插件可以申请文件读写、命令执行、网络访问等权限。但问题是很多社区插件在权限申请上是很贪的明明只需要读一个文件却申请了bypassPermissions级别的权限。这在本地开发环境里等于把整个机器都交给了插件的代码逻辑去支配。我现在的做法是装新插件前先翻一遍它的源码重点看它有没有把项目数据、提示词内容、日志往外发检查网络调用的地方有没有指向非官方端点。Codex 这边的沙箱机制read-only / workspace-write / danger-full-access 三档让我安心不少它默认你不需要全盘权限危险操作会先被拦住。2.3 依赖的纯净程度一个插件拉起一堆服务是要还债的有些插件为了做一个很小的功能会拉进来几十个 npm 包甚至还会在后台起一个常驻服务。这种插件短期用着没问题时间长了会有两件事很烦一是升级时经常出现依赖冲突二是它常驻的服务会吃掉额外内存和端口。我吃过一次亏装了一个看起来功能很多的插件结果它自带一个本地 server 组件每次启动 CLI 都会先拉起这个 server导致整个终端启动变慢好几秒。排查了半天才发现是这个插件搞的鬼。所以现在看到插件描述里出现自带服务daemon本地 server这类词我会格外谨慎。2.4 可迁移性为 Codex 留好后路这一点是最近才补上的新维度。既然 Codex 已经火起来了我选插件的时候会顺手评估一下这个插件如果将来要迁到 Codex迁移成本是高是低我自己的判断标准纯 MCP 型插件迁移成本最低两边都支持 MCP改一下配置格式就能用。Agent 型插件中等成本需要在 Codex 里用 AGENTS.md 加 prompts 的方式重写一部分逻辑。依赖 Claude Code Hooks 的插件迁移成本最高因为 Codex 现在没有 hooks 机制等于要重新设计这套能力。带着这个视角去选插件能帮你少走很多回头路。3. cc switch 这类配置路由工具是怎么把两套 CLI 捏在一起的很多人第一次听说 cc switch 是在搜索Claude Code 怎么切换模型供应商的时候。它最初是 claude-code-router 配套的切换管理工具后来开始支持管理 Codex 的供应商配置所以现在成了从 Claude Code 迁到 Codex 路上绕不开的一个工具。3.1 cc switch 到底在切什么别看界面简单背后是供应商路由cc switch 操作起来很简单就是选一个供应商、保存、切换。但理解它背后的原理对排查问题很有帮助。它的核心动作是在你的机器上启动一个本地路由服务这个服务会监听一个本地端口然后把你配置的 CLIClaude Code 或 Codex发出的 API 请求按照你选的供应商配置转发到对应的真实端点去。因为请求统一走这个本地服务所以切换供应商的时候CLI 本身不需要重启改路由配置就行。举个例子你在 Claude Code 里通过 cc switch 把供应商从官方切到某个第三方兼容服务实际上改的只是接到/v1/messages的请求该转发到哪里这件事。Codex 那边也是类似的逻辑只是它走的是另一个端点路径。3.2 接 ollama 等本地模型的配置思路cc switch 之所以在社区里火除了切换供应商方便还有一个重要用途接本地模型。很多人用 Ollama 在本地跑开源模型然后把 Claude Code 或 Codex 的请求路由到本地。这样调试 prompt、做批量简单任务的时候可以不消耗昂贵的云端额度。Ollama 的接入思路不复杂。它默认会在localhost:11434起一个服务并提供一个 OpenAI 兼容的 API所以配置的时候只需要在 cc switch 的供应商配置里把 base URL 指向http://localhost:11434/v1模型名填你本地已经拉下来的模型名称比如qwen2.5-coder之类。不过要注意本地模型的能力上限和云端模型差距很明显。我拿 Codex 配了本地模型做测试小任务比如写个函数、格式化代码问题不大但涉及工程级重构、多文件改动的时候本地模型的规划能力就不太够用了。所以我会把本地模型当成免费额度用完之后做轻量任务的兜底而不是完全替代云端的常规工作流。3.3 端点路由失败的典型症状与定位方法cc switch 用多了之后我遇到最多的报错是这种格式的cc switch local proxy failed while handling codex endpoint /responses.第一次看到这个报错的时候我愣了挺久因为前面几个词都是正常的唯独走到/responses这个路径的时候断了。后来定位的原因有三类路由服务版本过旧Codex 走的是 Responses API老版本的路由服务可能只实现了 Chat Completions 的转发识别不了新的/responses路径。解决方案很直接升级 cc switch 到最新版本。供应商配置缺字段某些第三方兼容服务要求补全特定字段比如模型映射、额外的鉴权头配置里没写全就会在转发环节被拒。本地服务端口冲突如果localhost:11434或者其他本地服务占用了 cc switch 的自定义端口路由服务就会起不来。排查的时候我一般按照从内到外的顺序先看 cc switch 的日志输出启动时是否成功监听端口再看具体请求到达了哪个环节有没有命中供应商配置最后看供应商边缘的响应是不是鉴权或字段问题。4. 迁移 Codex 的完整实操路径一步步搬别想一把梭如果你已经决定要迁到 Codex我最想给你的建议是不要想着一次全搬完而是按照资产分类一步一步来。以下是我实测过的一套路径。4.1 第一步盘点资产把 Claude Code 的插件和配置列全先把要迁移的东西全列出来。我在 Claude Code 里的资产包括插件slash commands、agents、MCP servers、~/.claude/CLAUDE.md和项目级 CLAUDE.md、环境变量、历史会话记录。用claude plugin list或者直接看~/.claude/plugins/目录把插件分成三类纯 MCP 型记下 server 名称、启动命令、参数、环境变量。Agent / 自定义命令型记下对应的 prompt 和工具配置。Hooks 型记下脚本路径和触发事件。这一步花的时间最值得因为后面所有操作都是围绕这份清单展开的。4.2 第二步CLAUDE.md 到 AGENTS.md记忆与规则的翻译Claude Code 的项目记忆是CLAUDE.mdCodex 对应的是AGENTS.md。虽然都是 Markdown但直接复制过去效果并不好。原因是两边的模型对指令格式的敏感度不同Claude 系模型可以接受比较自然的语言描述规则而 Codex 对结构化的规则块响应更好。我自己迁移时会把 CLAUDE.md 里的内容拆成几块项目概况与技术栈原样保留。代码风格与约束改成更明确的指令句式。比如新代码必须配套测试比记得写测试要有效得多。工具调用相关的说明删掉对 Claude Code 特有工具的描述替换成 Codex 能理解的描述。权限相关的内容Codex 的沙箱机制和 Claude 的 PermissionMode 不同CLAUDE.md 里那些permissions相关的描述要全部删掉否则模型会执行一些 Codex 沙箱里根本不存在的能力。4.3 第三步MCP 配置格式转换MCP 配置是迁移里最容易踩坑的部分。Claude Code 的 MCP 配置习惯放在.mcp.json或~/.claude.json里格式是 JSONCodex 的 MCP 配置写进~/.codex/config.toml格式是 TOML。两边配置项的对应关系大概是这样的Claude Code (JSON)Codex (TOML)说明mcpServers.name.command[mcp_servers.name]command启动命令mcpServers.name.argsargs参数数组mcpServers.name.envenv环境变量表举个例子JSON 里这样写{ mcpServers: { my-tool: { command: npx, args: [-y, some/mcp-server], env: { API_KEY: xxx } } } }到了 Codex 的 TOML 里就要改成[mcp_servers.my-tool] command npx args [-y, some/mcp-server] env { API_KEY xxx }转换本身不复杂但如果你插件很多手动改容易漏。我的做法是写个小脚本把 JSON 结构解析出来再按 TOML 模板输出半自动完成。另外提醒一句每个 MCP server 迁移后最好先跑一次简单的连通性测试确认能正常加载再继续下一个。4.4 第四步历史会话与本地记忆的迁移历史会话是个容易被忽略的迁移项。Claude Code 会把每次会话以 jsonl 格式存在~/.claude/projects/下按项目路径哈希分目录里面包含完整的用户消息、助手回复、工具调用记录。Codex 的会话记录放在~/.codex/sessions/新版或类似的项目目录结构下。这些历史记录没法直接翻译成 Codex 能用的会话但可以从中提取出有价值的信息。我会写一个小脚本把最近几个重要会话里模型给出的关键决策、我已经确认过的技术方案、踩坑结论提取成 Markdown然后合并进项目的AGENTS.md里。这相当于把你在 Claude Code 里积累的工作记忆以知识文档的形式输送给 Codex让新工具不至于从零开始理解你的项目。4.5 第五步验证清单迁移完成不等于结束我建议跑一遍自己的验证清单。我通常会用五个任务来测试打开项目、读取代码结构验证基本文件读取能力。按项目规范生成一个新函数验证 AGENTS.md 里的代码风格约束是否生效。调用一个 MCP 工具验证 MCP 配置是否正常加载、鉴权环境变量是否生效。做一次跨文件的小重构验证模型对项目上下文的理解深度。执行一次危险操作如 git push 或删除文件验证沙箱权限策略是否符合你的预期。任何一个环节没通过都说明前面的迁移还有遗漏。5. 迁移后最常踩的五个坑我替你试过了这部分是我最想分享的内容因为网上教程很少写到这一步。以下五个问题是我从 Claude Code 往 Codex 迁的过程里真实遇到的。5.1 插件树加载失败dsh 报 plugin tree failed to load 怎么救前面提过dsh: plugin tree failed to load: failed to apply loader entry include这个报错。我遇到它是在一次插件升级之后某个插件的loader配置指向了一个本地文件但那个文件在一次目录整理时被我挪走了于是整个插件树加载失败。排查的思路先把报错信息里的插件名找出来然后检查它的 plugin.json 里loader或include字段指向的路径是否存在。如果确实缺失有两种解法——把文件路径改回去或者干脆禁用那个插件等它更新了再启用。千万不要在一棵坏的插件树上做反复 reload那样只会得到更多的连带错误。5.2 模型行为不一致为什么同一个需求两边写出的代码风格差这么多迁移之后你很快会发现同一个 promptClaude Code 和 Codex 生成的代码风格差很多。这不是配置问题是模型本身的默认行为差异。Claude 系模型在复杂重构时往往更主动会自己判断哪些文件需要改动而 Codex 系的模型则更倾向于保守的小步改动不那么自作主张。解决办法是在 AGENTS.md 里非常明确地写清楚代码风格约束和改动的边界。越具体越好比如改动文件时先列出计划用户确认前不要批量修改函数命名遵循项目的现有前缀风格这类指令。别指望模型默认就懂你的项目规范显式的规则块通常会取得更好的效果。5.3 环境变量被吞路径和密钥的坑MCP server 迁移到 Codex 之后如果发现工具调用时报鉴权失败或找不到路径十有八九是环境变量没配对。Claude Code 的配置里环境变量可以直接引用 shell 里的变量而 Codex 的 config.toml 里env表是静态字符串赋值不会自动展开你的$HOME或$PATH引用。我踩过一次某个 MCP server 依赖DATABASE_URL环境变量在 Claude Code 里它是从 shell 自动继承的到了 Codex 里根本没传进去。修法是把需要的变量显式写进env里或者用一个启动脚本包一层在脚本里 export 之后再拉起 MCP server。5.4 供应商配置错误响应端点 404 的问题在 Codex 里配置第三方供应商的时候我遇到过几次 404 错误。排查下来都是 base URL 写得太粗导致的。Codex 走的是 Responses API所以 base URL 需要精确到能拼接出/responses路径的那一级。如果你在配置里加了一个带/v1或别的子路径的 URL非常容易拼出https://xxx/v1/chat/completions这种错误请求。5.5 权限模式差异沙箱 vs 逐次批准Claude Code 的 PermissionMode 是逐次询问式的一个操作来了让你选允许还是拒绝你有很强的临场控制感。而 Codex 的沙箱模式更接近预分配权限范围read-only 模式里它根本不会写文件workspace-write 模式里它只能改工作区内的文件danger-full-access 才放行所有操作。这种差异让我一开始很不适应总觉得 Codex 太自作主張或者太呆。后来意识到这是个习惯问题在 Claude Code 里你是靠人肉判断拦危险操作在 Codex 里你是靠提前划好的权限边界拦危险操作。迁过来之后别偷懒给不同项目设置好对应的沙箱档位比事后后悔强得多。6. 我的最终建议不是二选一而是双轨并行折腾完这一圈我现在的状态不是从 Claude Code 全面迁到 Codex而是双轨并行。这么说可能让一些想看到二选一结论的朋友失望但说实话这两套工具的长处恰好错开了。6.1 什么场景留在 Claude Code我仍然会在 Claude Code 里处理需要深度上下文理解的重活跨十几个文件的大重构、梳理历史遗留代码的调用关系、需要反复斟酌的架构调整。我攒下的 agents 和 hooks 在这些场景里已经调教得很顺手值得一提。而且我那些依赖 hooks 的插件比如在文件写入前自动做格式检查、在命令执行前做安全检查的脚本目前只有 Claude Code 能原生支持。这些能力迁到 Codex 要重写一大套逻辑性价比不高。6.2 什么场景交给 CodexCodex 这边我主要用来做三类事一是快速实现明确的小功能比如按规范写一个新组件二是在已经有 AGENTS.md 强约束的项目里做代码补全和格式化三是用本地模型跑一些低成本的批量任务不占用 Claude 的额度。说白了Codex 在我的工作流里更像一个纪律严明的执行者而 Claude Code 更像一个能力全面的搭档。前者适合规范明确的重复劳动后者适合需要临场判断的复杂工作。6.3 双轨并行的目录与配置管理技巧双轨运行最头疼的是两份记忆文件的同步。我的做法是用符号链接把项目根目录的CLAUDE.md和AGENTS.md指向同一个文件。这样一份规则两个工具都能读到。规则内容里同时考虑了两边的模型特性尽量用中性、结构化的语言描述让 Claude 和 Codex 都能理解。供应商配置也一样。我把 cc switch 里同时配好 Claude Code 和 Codex 两套供应商切换的时候只需要一个命令。虽然一开始要多花点时间配置但之后的日常使用非常顺畅。最后分享一个我自己的小习惯迁完 Codex 之后不要急着删掉 Claude Code 的插件目录把那些暂时用不上的 hooks 和 agents 留在一个备份目录里。因为随着两边工具迭代今天的无法迁移说不定下个月就有官方方案了。我最近就在关注 Codex 是否会把 hooks 能力补上如果补上我那些曾经放弃迁移的插件就又有救了。工具在变工作流也在变留一手总比到时候重新造轮子强。