从Claude Code或者Cursor切到Codex，很多人最先关心的是：

历史聊天、规则、Skills能不能一起搬过去？

现在Codex已经提供正式的Import能力。桌面端可以从其他Agent导入支持的配置和近期工作，CLI里也可以直接使用：

/import

目前官方已经扩展到支持迁移Claude Code和Cursor的Settings、MCP Servers、Plugins、Sessions、Commands以及Project Memories等内容。

但真正需要注意的是：

Import成功，不等于迁移已经完成。

因为Coding Agent真正能不能稳定工作，取决于的不只是聊天记录，而是整套：

Instructions
↓
Skills
↓
Tools
↓
Environment
↓
Permissions
↓
Verification

所以从Claude Code / Cursor迁到Codex以后，我更建议重点检查下面6个地方。

---

一、Instructions迁过来了，规则真的还一样吗？

迁移Agent工具，最重要的往往不是Chat，而是项目规则。

Claude Code里可能已经有：

CLAUDE.md

Cursor也可能积累了自己的Project Rules。

进入Codex以后，这些长期规则最终需要和Codex的：

AGENTS.md

体系配合。

Codex会在开始任务之前读取AGENTS.md，而且支持全局规则、项目规则以及更靠近当前目录的覆盖规则。

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

AGENTS.md有没有生成。

还要看：

Global Rule
↓
Project Rule
↓
Directory Rule

最终到底哪一层生效。

例如旧规则写：

修改完成以后必须运行测试。

但Codex项目真正的统一验证入口可能已经变成：

./scripts/verify

这时候规则虽然没有丢，

执行方式却已经不一样。

所以第一项检查应该是：

Rule
→ Command
→ Verification

三者还能不能对应。

---

二、Skills能导入，不代表Skill一定能跑

Skill很容易让人产生一种错觉：

文件已经迁过来了，那就能直接继续用。

实际上一个Skill通常不只是几行Prompt。

它可能依赖：

Instructions
Scripts
CLI Tools
Files
MCP
Environment Variables
Permissions

Codex当前的Skill体系本身就允许把Instructions、Resources和可选Scripts封装成可复用能力。

所以迁移以后至少要做一次Smoke Test。

可以先选三种Skill：

纯文本Skill

例如：

代码解释、文档整理。

检查是否能正确触发。

Shell Skill

例如：

Test、Build、Lint。

检查命令和依赖是否正常。

外部工具Skill

例如：

GitHub、Database、MCP。

检查授权和Tool Call是否还能成功。

真正应该验证的是：

Skill Detected
↓
Dependencies Ready
↓
Tool Available
↓
Result Verifiable

而不是只看：

Skill文件存在。

---

三、MCP和Plugins最容易卡在“配置有了，授权没了”

这是迁移里非常常见的一类问题。

例如MCP Server地址已经成功迁入Codex。

界面也显示配置存在。

但真正调用时出现：

401
403
Authentication Failed

原因通常不是Server没迁过来。

而是：

OAuth
API Key
Custom Header
Environment Variable

这些认证状态没有完全恢复。

当前Codex配置体系本身也把Integrations、MCP以及Provider配置作为独立配置层管理。

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

Connected

至少继续测试：

Server
↓
Tool Discovery
↓
Real Tool Call
↓
Result

比如GitHub工具，

真正需要验证的是：

能不能读取Repository、Issue或者执行允许的Action？

这才说明Workflow恢复了。

---

四、最容易被忽略的是Environment

有些迁移看起来所有配置都正常：

Instructions有了。

Skill有了。

MCP也有了。

结果一执行：

项目还是跑不起来。

因为真正缺的是：

Runtime Environment。

例如原来的开发环境里已经存在：

PATH
.env
NODE_ENV
DATABASE_URL
Python venv
Private Registry

这些东西并不会因为Agent配置迁移，就自动变成完全相同的Codex运行环境。

于是就会出现：

Skill正确
↓
Command正确
↓
Environment缺失
↓
Execution Failed

所以迁移完成以后，一定重新检查：

Dependencies
Environment Variables
Shell
Git
Network
Credentials

尤其是Shell环境。

很多所谓的“Agent兼容问题”，最终其实只是：

原环境里的隐式配置没有被重新建立。

---

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

把过去Chat导进Codex当然很有价值。

因为里面可能保存着：

为什么选择某套架构；

哪些方案已经试过；

某个Bug之前怎么处理。

Codex现在也支持把有价值的历史上下文沉淀为Memory。

但必须记住：

Historical Context
≠
Current Source of Truth

比如10天前的Chat写着：

Project uses API v1

现在代码已经迁到：

API v2

如果Agent继续把旧Decision当当前事实，

迁移反而会引入：

Stale Context。

所以历史Chat和Memory迁入以后，最好重点检查：

旧路径还存在吗？
旧API还有效吗？
旧依赖还在吗？
旧架构Decision还成立吗？

真正稳定的做法是：

把历史内容当成：

Past Evidence。

当前Repository才是：

Current Truth。

---

六、Sandbox和Approval一定要重新检查

这是我最不建议直接照搬的一层。

因为不同Agent工具对：

文件；

Shell；

网络；

高风险Action

的权限模型可能并不完全相同。

Codex现在把：

Sandbox

和：

Approval Policy

分开管理。

Sandbox决定Codex技术上能访问哪些文件和网络资源，Approval决定哪些动作执行前需要暂停并请求确认。

所以迁移以后不要第一件事就：

Full Access

更稳的是：

Import
↓
Limited Permission
↓
Test Workflow
↓
Verify
↓
Expand Access

尤其当你同时迁入了：

Skills；

MCP；

Commands；

Hooks

以后。

因为这时候你还没有完全确认：

这些旧能力在Codex环境里会产生什么Action。

未知配置 + 最大权限

反而是最需要避免的组合。

---

一套更简单的迁移检查流程

从Claude Code / Cursor迁到Codex以后，不需要一次检查几十项。

先抓住这6个就够了：

① Instructions
规则是否正确？

② Skills
能否真正执行？

③ Plugins / MCP
是否需要重新授权？

④ Environment
依赖、Shell、变量是否完整？

⑤ Chat / Memory
旧Context是否已经过期？

⑥ Permission
Sandbox和Approval是否需要重设？

最后再选择一个低风险真实任务：

Read
↓
Modify
↓
Test
↓
Verify

完整跑一次。

如果这条链能闭环，

才说明：

迁移基本完成。

---

最后

Codex现在的 /import 已经明显降低了从Claude Code和Cursor迁移的门槛，官方也在持续扩大可导入的Settings、MCP、Plugins、Sessions、Commands和Project Memories范围。

但Agent迁移和普通IDE迁移最大的不同是：

迁的并不只是文件。

而是：

Rules
Context
Capabilities
Environment
Permissions

所以真正需要建立的判断是：

Imported
≠
Ready

还应该继续：

Import
↓
Review
↓
Reconnect
↓
Test
↓
Verify

特别是：

Instructions、Skills、MCP、Environment和权限

这几层。

不要只确认：

东西有没有搬过来。

更重要的是确认：

搬过来以后，Codex还能不能按照原来预期的边界和Workflow稳定完成任务。

这才是真正完成从Claude Code / Cursor迁移到Codex的标志。

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