从 Claude Code 迁到 Codex，要关心的不止是配置

从 Claude Code 迁到 Codex，配置迁移反而是最简单的一步。

Codex 能自动识别并导入 CLAUDE.md、Skill、Command 和 Agent。真正开始工作以后，仍有一些内容需要手动调整，也需要重新考虑 Codex 和 Claude 之间的分工。

这篇文章记录的就是这次迁移过程。

我开始迁移，不是为了尝鲜。

Opus 最近越来越不好用，Fable 虽然能力更强，但价格太高。我所在的行业又是医疗，项目需求中经常出现疾病、诊断、用药等词，频繁触发 Fable 的安全机制，随后自动降级到 Opus。

模型一旦切换，复杂任务的执行质量和稳定性都会受到影响。当这种情况开始妨碍日常开发，我决定把项目开发逐步迁到 Codex。

我原以为最麻烦的是搬 CLAUDE.md、Skill 和各种配置。结果 Codex 打开旧项目后，直接弹出了导入窗口。配置几分钟就搬完了，需要手动处理的问题反而出现在导入之后。

Codex 怎么知道这是一个 Claude 项目

我第一次迁移时，没有手动复制文件，也没有对着两套配置目录逐项修改。

在 Codex App 里点击项目旁边的 +，选择使用现有项目，然后打开原来用 Claude Code 的项目，Codex 会自动探测里面的 Claude 配置。识别到以后，界面直接弹出一句：

请选择要导入的设置

它在我的项目里识别出了四类内容：

• CLAUDE.md

• Skill

• Command

• Agent

选中需要的内容，确认导入，迁移的第一步就做完了。如果打开项目时跳过了这个窗口，后面也能从设置里手动启动迁移。

这两个入口解决的是同一件事。第一次打开旧项目，跟着弹窗走最省事；当时没迁，或者想稍后再处理，就去设置里手动导入。

我原本给自己留了半天，准备处理配置文件、目录和格式差异。实际操作下来，这部分只用了几分钟。

自动探测到了，为什么还不算迁完

导入结束后，我先拿一个日常开发的代码仓库做验证。

这个仓库里既有前后端代码，也有编译启动脚本、文档资料和测试脚本。Claude Code 里还接入了一些开源 Skill 和工具，也有自己写的 Command 和 Skill，比如负责数据库查询的 db-query。

迁到 Codex 后，项目规则、开源 Skill 和工具基本都能正常识别。Codex 能读懂前后端目录，也能找到仓库里的编译、启动和测试脚本。

问题出在我准备调用 db-query 时：原来的 Command 虽然出现在导入结果里，却不能继续按 Claude Code 的方式使用。

这次验证里，需要手动处理的是 Command 和 CLAUDE.local.md。

Command 被识别了，但不能继续照旧使用

导入窗口能探测到 Claude Command，不代表 Codex 还会按 Claude Code 的方式执行它。

我原来的 Command 需要改成 Skill。Command 更像一个快捷入口，Skill 则包含完整的执行流程。迁移时不能只看导入列表，还得真的调用一次。

我的处理方式很简单：不批量重写所有 Command，只迁高频使用的。用到哪个，就把哪个整理成 Skill。这样还能顺手删掉长期没用过的旧命令。

CLAUDE.local.md 需要单独处理

另一个问题是 CLAUDE.local.md。

Claude Code 可以用它保存个人或本地规则，又不用把内容提交到项目里。这次自动导入没有处理它。里面还需要保留的内容，要改为通过 AGENTS.md 单独引用。

这一步不能偷懒。CLAUDE.local.md 里经常放着个人路径、本机命令或只适合自己的偏好。直接合并进团队共享的 AGENTS.md，很容易把本地配置带给整个项目。

所以我现在会把内容分一遍：团队都要遵守的规则写进项目级 AGENTS.md；只跟自己环境有关的内容继续放在独立文件中，再按需引用。

还需要注意的一点是，CLAUDE.md 变成 AGENTS.md 不能只靠改文件名。旧文件里有不少针对 Claude Code 行为写的“补丁”，搬到 Codex 后未必还有必要。

导入完成后，我更关心两件事：哪些旧规则该删，哪些要求要写得更具体。

从 CLI 到 App，变化有想象中大吗

从 Claude Code CLI 换到 Codex App，最直观的变化当然是界面。

以前大部分操作都在终端里完成。现在任务、对话、文件改动和执行进度都放到了 UI 中，查看、切换和预览更方便。

尤其是做界面设计或 PPT 这类展示型工作时，App 的优势很直接，不需要在终端、文件管理器和预览工具之间反复切换。

但用了几天以后，我觉得两者没有那么大差别。你仍然是在描述任务、提供上下文、观察执行过程，然后验收结果。UI 改变的是入口和信息呈现，不是 Agent 工作的基本逻辑。

这反而降低了我的迁移成本。Claude Code CLI 里形成的任务拆分和验收习惯，大部分还能继续用。

需要重新适应的，主要是 Codex App 里的任务组织方式，以及什么时候打断、什么时候引导、什么时候把新要求排到下一轮。

这些操作我之前单独写过一篇，这里不再展开。从 CLI 到 UI 需要适应，但没有重新学一套工具那么夸张。

我没有卸载 Claude Code

迁移后，我没有急着做“Claude Code 和 Codex 到底谁更强”的结论，也没有把 Claude Code 卸掉。

现在我的分工很明确：

• 项目需求开发逐渐以 Codex 为主。

• 需要长时间深度推理的任务，暂时继续用 Claude。

• 内容创作目前也保留在 Claude。

这个分法未必适合所有人，但解决了我的实际问题。项目开发看重稳定执行、规则继承和过程管理，Codex 更符合我现在的需要。

深度推理和创作又是另一回事。我没必要为了“迁移完成”四个字，把所有工作都塞给同一个工具。

如果你也准备迁，可以按这个顺序来：

• 先用 Codex 的导入功能搬现有配置。

• 选一个熟悉的小项目，验证规则和常用 Skill。

• 把仍在使用的 Command 逐个改成 Skill。

• 单独检查 CLAUDE.local.md，不要直接并入共享规则。

• Claude Code 先留着，用一段时间再决定任务怎么分。

权限也建议先保守一点。新工具能读到旧规则，不等于你已经了解它在所有场景里的行为。跑过几个真实任务，再逐步放开，比一开始追求全自动省事。

搬完配置之后，我怎么选

回头看，这次迁移比我预想中简单。

Codex 能自动识别 CLAUDE.md、Skill、Command 和 Agent，省掉了大量复制配置的工作。需要手动处理的主要有两处：原来的 Command 要改成 Skill，CLAUDE.local.md 里的本地规则也要重新安排。

我没有因此卸载 Claude Code。现在项目需求开发逐渐以 Codex 为主，深度推理和内容创作暂时继续使用 Claude。

迁移之后，我不再纠结 Claude Code 和 Codex 谁更强。项目开发需要稳定执行，我就用 Codex；深度推理和创作仍然适合 Claude，我就继续保留。

工具不必选边站，能稳定完成手上的任务就够了。

历史文章：

从裸奔到全副武装：Claude Code 10 个精选仓库

所谓“必装 Skill 清单“，正在毁掉你的 AI

我把耳机线控键改成了豆包语音输入

一个SKILL仓库13 个文件,只有 1 个真正属于我

实测 78k star 的 claude-mem：跨会话记忆让 token 少了一半

高考志愿填报：试试这个开源的雪峰Agent

10个AI写作提示词，让输出真正能用

Hi，我是 爱学习的Niko。17 年程序员老兵，现在每天用 AI 写代码，搞创作。这里分享学习和使用 AI 的经验、技术思考、踩过的坑、实用工具和 SKILL。关注我，一起学习。