从Claude Code或者Cursor迁到Codex，很多人最关心的是：原来的项目规则、Skills、MCP和历史工作能不能一起带过去？

现在Codex已经提供Import能力，CLI里可以直接使用 /import，选择Claude Code或者Cursor作为来源，再导入支持的配置、项目内容和近期工作。

从操作上看，迁移已经比以前简单很多。

但真正容易出问题的地方，并不是“能不能导入”，而是：

导入以后，原来的开发Workflow还能不能按照同样的规则稳定运行？

因为Coding Agent真正依赖的从来不只是聊天记录，而是一整套运行条件：Instructions、Skills、MCP、Runtime Environment、历史Context以及权限边界。

所以从Claude Code / Cursor迁到Codex，更准确的理解不是“复制配置”，而是重新建立一套Agent运行环境。

一、迁移后第一件事，应该先检查项目规则

Coding Agent用久以后，真正有价值的往往不是某一段聊天，而是已经沉淀下来的项目规则。

比如哪些目录不能修改、改完以后需要执行什么测试、什么时候必须完整Build、哪些文件只允许读取，以及任务做到什么程度才算完成。

迁到Codex以后，这些长期规则需要进入Codex的AGENTS.md体系。

这里最容易出现的问题不是规则完全丢失，而是规则的生效范围发生变化。

Codex会根据Project Root和当前Working Directory加载不同层级的项目Instructions。同一个Repository，如果从根目录开始任务，和从某个子目录开始任务，最终Agent拿到的规则可能不同。

例如根目录要求所有修改完成后执行完整测试，而某个支付模块又单独规定使用自己的验证脚本。Working Directory一旦发生变化，实际生效的规则也可能变化。

所以迁移以后不要只检查：

“AGENTS.md有没有生成？”

更重要的是重新确认：

Project Root在哪里、Codex现在从哪个目录工作、最终真正生效的是哪一组规则。

很多所谓“迁到Codex以后行为变了”，最后并不是模型变笨了，而是Instruction Boundary发生了变化。

迁完以后，最好重新确认一次安装、Build、Test、禁止修改区域和完成标准。

规则文件可以搬，但Execution Contract最好重新验证。

二、Skills看得到，不代表Workflow已经恢复

Skills是第二个特别容易误判的地方。

原来的Skill已经出现在Codex里，很容易让人觉得迁移结束了。

但一个真正能工作的Skill，往往不只是几段Prompt。

它可能同时依赖脚本、CLI工具、环境变量、外部文件、MCP和特定权限。

比如原来有一个Skill负责读取Issue、定位代码、修改文件、运行测试并生成PR说明。

Skill本身迁过来了，但如果GitHub认证没有恢复，或者测试需要的CLI在当前环境中不存在，这个Workflow依然跑不完整。

所以Skills迁完以后，不需要一次性全部测试。

先选择三类最有代表性的能力即可。

第一类是纯Instruction Skill，例如代码解释、文档整理，主要看规则有没有正确触发。

第二类是Shell Skill，例如Build、Lint、Test，检查Runtime和命令是否正常。

第三类是External Tool Skill，例如GitHub、Database或者MCP，检查授权和真实调用是否能够完成。

真正判断Skill是否迁移成功，看的不是：

Skill文件存在。

而是：

这个Skill能不能完整完成一次真实任务。

这两个标准差别很大。

三、MCP最容易出现“配置迁了，认证没恢复”

MCP迁移以后经常出现一种很典型的情况：

Server已经显示在Codex里，配置看起来也没有问题，但第一次真正调用就出现401、403或者Authentication Failed。

原因往往不是MCP没有迁过来，而是认证状态并不完全包含在普通配置里。

Server地址、启动方式和Tool定义可以迁移，但OAuth、Token、环境变量或者其他Credential仍然可能需要重新确认。

所以迁移MCP以后，不要停留在：

“已经Connected。”

至少真正完成一次调用。

例如GitHub MCP，真正需要验证的是：Agent能不能读取当前Repository、读取Issue，或者执行你允许的操作。

如果只能看到Server，但真实Tool Call无法完成，这仍然只是：

Configuration Ready。

还不是：

Workflow Ready。

原来Claude Code或者Cursor里外部工具连接得越多，这一步越值得认真检查。

因为Agent真正进入复杂Workflow以后，MCP认证断掉往往不会在任务开始阶段就暴露，而是做到一半调用Tool时才失败。

四、最容易被忽略的其实是运行环境

这也是迁移以后最容易让人误判成“Codex兼容性问题”的地方。

有时候AGENTS.md已经正常，Skills也在，MCP也能看到。

但真正开始执行项目时，却出现Node找不到、Python版本不对、数据库无法连接或者某个环境变量缺失。

这时候很容易产生一个疑问：

Claude Code原来明明可以跑，为什么Codex不行？

真正的问题经常只是：

Agent配置迁过来了，但Runtime Environment并没有完全等价。

开发者自己的机器上往往存在大量隐式条件。

比如PATH、NVM、PYENV、JAVA_HOME、.env、本地数据库、Private Registry、Git Credential。

因为平时一直都在，人已经习惯这些东西默认存在。

但对Agent来说，它们全部属于运行依赖。

所以迁到Codex以后，最好重新建立一份最小Environment Baseline。

至少明确：

Runtime版本是什么、Package Manager用什么、依赖怎么安装、Build怎么跑、Test怎么跑、需要哪些环境变量、依赖什么本地服务。

例如Node项目，不要只写“安装依赖”。

最好明确Node版本、pnpm还是npm、Build和Test命令，以及PostgreSQL或者Redis是否必须启动。

真正适合Agent长期工作的项目，不应该依赖：

“这台电脑以前刚好可以运行。”

而应该尽量做到：

Setup可以重建，Run可以重复，Verify有明确入口。

如果迁移后这一层没有检查，很多所谓Agent问题最后其实只是Runtime Drift。

五、历史Chat最危险的不是丢失，而是过期

把以前的Recent Chats一起迁入Codex当然很有价值。

因为里面可能记录着架构为什么这样设计、哪些方案已经失败、一个Bug之前查到哪里，以及团队做过什么Decision。

这些Context可以让Agent少走很多弯路。

但它同时会产生新的风险：

Stale Context。

例如10天前的Chat明确写着项目仍然使用API v1，但今天Repository已经完成API v2迁移。

如果Codex继续把旧Chat里的结论当作Current Truth，它就会基于一个已经不存在的代码状态继续分析。

所以历史Chat迁过来以后，真正重要的不是“让Agent全部记住”，而是重新区分：

哪些只是过去发生过的事实，哪些现在仍然成立。

文件路径、Branch、API版本、依赖版本、架构Decision和测试状态，这些容易变化的信息，最好重新回到Repository确认。

可以记住一句非常实用的话：

历史Chat是Past Evidence，当前Repository才是Current Truth。

旧Context可以帮助恢复思路，但不能替代当前代码状态。

Agent开始拥有更长期的Context以后，真正重要的不只是Remember，还必须有Revalidate。

六、权限不要照搬，更不要迁完直接Full Access

这一项我认为是整个迁移里最容易被低估的风险。

迁移完成以后，Codex可能已经拥有原来的Instructions、Skills、MCP、Plugins以及历史Workflow。

看起来和旧环境越接近越好。

但问题是，你还没有完全验证这些能力在Codex环境里最终会产生什么Action。

如果这时候直接Full Access，相当于把：

尚未完全验证的旧配置 + 最大执行权限

直接组合在了一起。

更稳的方式是先导入、检查配置，然后用较小权限运行一个低风险任务。等确认行为符合预期，再逐渐扩大权限。

尤其涉及Shell、Network、Git Push、External API和文件写入时，更应该重新检查。

迁移的目标并不是：

让Codex获得和旧Agent一样大的权限。

真正应该问的是：

这个Workflow现在实际需要哪些权限？

所以Agent迁移本质上并不是一次简单的Configuration Copy。

它更像是一次：

Trust Re-establishment。

工具换了以后，规则、环境、外部连接和权限边界都应该重新建立信任，而不是默认完全等价。

七、迁完不要马上跑大项目，先做一次Smoke Test

从Claude Code或者Cursor导入完成以后，最不建议做的事情就是第一句话：

帮我重构整个Repository。

更稳的方式，是先给Codex一个低风险、能够完整验证的小任务。

例如：

“找到这个模块对应的测试命令，修复一个小问题，只修改必要文件，并运行对应测试。”

别看任务很小，它一次可以验证很多东西。

Codex有没有加载正确的项目规则？

Skill能不能正常工作？

MCP或者外部Tool能不能调用？

Runtime是否完整？

文件权限是否合理？

测试命令是否能够执行？

最终Diff有没有出现意外修改？

如果这个小任务能够完整跑通，说明迁移的大部分关键层已经基本对齐。

如果失败，也比较容易判断问题到底出在Instructions、Environment、Tool还是Permission。

所以更合理的迁移过程应该是：

Import → Review → Reconnect → Smoke Test → Verify → Scale Up

而不是：

/import → Migration Done

真正的迁移完成，不是看到导入页面显示Success，而是原来的真实Workflow能够在Codex里重新跑通。

最后

Codex的 /import 的确降低了从Claude Code和Cursor迁移的门槛。

但Agent迁移和普通IDE迁移不是同一件事。

IDE迁移主要搬的是插件、主题和快捷键。

Agent迁移真正搬的是：

Rules、Capabilities、Context、Environment和Permissions。

这些东西决定了Agent怎么理解项目、能调用什么、能够执行到什么程度，以及最终怎样判断任务完成。

所以迁到Codex以后，最值得重新检查的就是6层：

Instructions是否仍然正确生效；Skills能不能真正执行；MCP认证是否恢复；Environment是否等价；历史Context是否已经过期；Permission是否仍然合理。

把这些重新验证一遍，再用一个小任务跑完整闭环，才算真正完成迁移。

所以这篇真正值得记住的，不是 /import 这个命令本身。

而是：

Imported ≠ Ready。

只有旧Workflow在新的Agent环境里重新通过验证，Claude Code / Cursor到Codex的迁移才真正结束。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道已放置下方。