OpenAI让从Claude Code迁移到Codex变得更加容易

引言

在 AI 编程工具中，最难替代的往往不是订阅费用。

而是开发者围绕工具积累的一切：一份精心调校的 CLAUDE.md、数十个小的工作流技巧、MCP 服务器权限、斜杠命令、技能、项目记忆，以及数月的聊天记录。

这些文件可能静静地存放在开发者的电脑上，但它们合在一起就构成了一本 AI 编程工作流操作手册。从 Claude Code 迁移到另一个工具，如果没有迁移支持，大部分这些配置都必须从头重建。

OpenAI 现在让这种切换变得容易得多。

根据 OpenAI 当前的文档，ChatGPT 桌面应用可以导入来自 Claude Code、Claude Cowork 和 Cursor 的支持的配置和近期工作。Codex CLI 可以从 Claude Code 和 Cursor 导入，同时保留现有配置而不是删除或替换它。

这听起来像是一个简单的便利功能。但实际上，它改变了开发者在不同 AI 编程工具之间切换时面临的摩擦程度。

OpenAI 正在打包 Claude Code 用户的配置

OpenAI 最近将其外部代理导入说明整合到了单一工作流中。

在 ChatGPT 桌面应用中，用户可以打开 设置 → 导入 并选择受支持的代理，如 Claude Code、Claude Cowork 或 Cursor。在 Codex CLI 中，对应的入口点是：

/import

当前官方文档表明，桌面应用可以导入指令、设置、技能、插件、项目和近期工作。Codex CLI 可以从 Claude Code 或 Cursor 导入支持的配置、项目文件和近期聊天记录。

重要的细节是，导入是复制而非破坏性迁移。

OpenAI 的文档明确指出，导入不会更改或删除现有代理配置。换句话说，你的 Claude Code 或 Cursor 配置保留在原位，而 Codex 接收自己的导入版本。

这使得整个过程感觉不像是在替换一个工具，而更像是将现有的开发环境带入第二个工具中。

迁移的内容比你预期的要多

官方导入文档提供了源配置到 Codex 目标的相当详细的映射。

源项目	Codex 目标
指令文件	AGENTS.md
settings.json	config.toml
技能	技能
插件	插件
现有项目文件夹	使用相同文件夹的项目
来自 Claude Code 的项目记忆	记忆
最近 30 天的聊天记录	ChatGPT 聊天记录
MCP 服务器配置	Codex MCP 配置
钩子	Codex 钩子
斜杠命令	技能
子代理	Codex 代理

因此，转换并不总是简单的文件复制。

诸如 CLAUDE.md 之类的 Claude Code 指令文件会变成 AGENTS.md。Claude Code 的 settings.json 会被转换为 Codex 的 config.toml。斜杠命令被映射到技能中，而子代理则变成 Codex 代理。

这种区别很重要，因为成功的导入并不一定意味着每个项目之后的行为都完全相同。

名称可能会改变，

配置格式可能会发生变化，执行模型也会随之变化。

项目是复用而非作为新副本上传

项目迁移是另一个有用的细节。

OpenAI 的文档说明，现有项目文件夹会以使用相同文件夹的方式作为项目导入。因此，工作流程不需要为了在 Codex 中继续使用而复制整个仓库。

导入界面还允许用户选择要带入的内容，而不是强制进行全有或全无的迁移。

这意味着设置、指令、技能、插件、项目和聊天记录都可以作为迁移的独立部分进行审查。

导入后可以继续旧的对话

迁移还有另一个实际问题：旧的对话可能太大，目标工具无法一次性处理。

Codex 通过上下文管理来处理这个问题，而不是简单地拒绝导入的对话。

OpenAI 当前的文档说明，Codex CLI 可以从最近 30 天导入最多 50 个聊天。桌面导入流程也支持最近的聊天，并允许用户从导入的项目或对话中继续工作。

源文章将体验描述如下：当迁移的 Claude Code 对话过长时，Codex 可以在用户首次继续该导入对话时压缩早期内容，为下一轮释放上下文。

实际目标很简单：迁移不应该以一份巨大的导入记录结束，然后立即变得不可用。

这个导入流程一直在扩展

源文章追踪了该功能在 Codex 多个版本中的演进。

文章报道说，/import 首次出现在 Codex CLI 0.140.0 中，支持较窄范围的 Claude Code 导入。后续版本扩展了工作流程，增加了额外的迁移区域，随后又增加了 Cursor 技能支持和导入会话的同步。

具体的发布历史有助于理解该功能演进的速度，但对于当前支持的内容，现有的官方文档是更好的参考。它确认了导入工作流程现在覆盖了比早期版本更广泛的代理设置和近期工作范围。

在实践中仍然是单向迁移

源文章做了一个更敏锐的观察：迁移文档侧重于导入到 Codex，而不是将 Codex 配置导回 Claude Code。

这里有一个重要的区别。

OpenAI 当前的文档支持在 ChatGPT 桌面应用中从原始代理自动更新到导入的设置中。用户可以在设置 → 导入中启用自动更新，并在那里查看导入历史。

这并不意味着在 Codex 中所做的编辑会自动写回 Claude Code 或 Cursor。

方向仍然很重要：原始环境可以继续向导入的副本提供更新，但导入的副本并不是作为双向同步层呈现的。

对于开发者来说，这意味着在启用自动更新之前，值得决定哪个环境是权威来源。

OpenAI 和 Anthropic 正在以不同的方式处理迁移

更广泛的

竞争不仅仅局限于OpenAI。

来源文章指出，Anthropic 也一直在开发旨在将用户上下文引入 Claude 的迁移工具。Anthropic 目前的帮助文档还为其 Claude 用户提供了官方的数据导出流程，包括对话历史和账户数据。

这造成了理念上的显著差异。

如果一个平台同时支持导入和导出，用户就能更自由地迁移他们积累的上下文。如果迁移主要只是单向流动，那么该功能也可能成为降低用户转向目标平台摩擦的有力工具。

技术细节有所不同，但战略问题是一样的：开发者积累的 AI 工作流归谁所有，它的可移植性有多高？

OpenAI 也将 Codex 放入了 Claude Code

在扩展其导入流程之前，OpenAI 已经朝着相反的方向采取了行动。

其开源的 codex-plugin-cc 项目让开发者能够在 Claude Code 内部使用 Codex 进行代码审查和委派任务。该插件包含诸如 /codex:review 和 /codex:transfer 之类的命令，其中后者可以从一个 Claude Code 会话创建一个持久的 Codex 线程。

该代码库以 Apache-2.0 许可证发布，并由 OpenAI 维护。

/codex:transfer 工作流与迁移的故事尤其相关。

插件文档指出，它可以获取当前的 Claude Code 会话并创建一个持久的 Codex 线程，从而允许工作直接在 Codex 中继续。该传输使用 Codex 的外部代理会话导入器，并遵循与 Claude 历史记录导入相同的转换规则。

这与简单地开启一个新的 Codex 对话体验不同。

其目标是跨越边界携带工作上下文本身。

仍有四件事无法顺利迁移

一个迁移按钮可以消除很多摩擦，但它无法让两个不同的编码代理变得完全相同。

来源文章强调了开发者应预期需要手动处理的四个领域。

1. 权限

Claude Code 可能包含围绕特定文件、命令、工具和工作流精心调校的权限规则。

Codex 有自己的权限和沙箱模型。因此，导入的与权限相关的设置需要审查，而不能假设它们是等效的。

OpenAI 的文档特别建议在迁移后审查导入的技能和代理中的工具限制和权限。

重要的一点是，权限迁移关乎保留原始意图，而不仅仅是重命名设置。

2. 钩子

钩子是另一个行为可能出现差异的领域。

OpenAI 的导入文档明确警告说，导入的钩子可能在迁移后表现不同，应进行审查。

简单的钩子可能可以顺利转移。更复杂的、带有条件、环境假设或异步行为的链条可能需要为目标工具重新设计。

所以这并不总是一个转换问题。有时这是一个工作流重新设计的问题。

3. 模型也会改变

这可能是最明显的差异，但也是最容易被忽视的差异之一。

你可以移动你的

指令、技能、MCP配置、项目文件以及记忆可以被导入到Codex中，但执行这些指令的模型仍然不同。

为Claude的行为调优过的提示词或CLAUDE.md文件，在由OpenAI模型执行时，可能不会产生完全相同的结果。

配置可能已成功迁移，但其背后的行为已发生变化。

原文指出，Codex是围绕OpenAI自身模型和基于Responses的工作流设计的。希望将Codex路由到自定义提供商的开发者，需要将其视为一项独立的配置任务，而不能假设导入的Claude模型配置会自动延续。

4. 聊天历史有边界

并非所有对话都符合迁移条件。

OpenAI当前文档显示，Codex CLI最多导入最近30天内的50段聊天。/import命令也存在操作限制：它在任务运行中、远程会话中或连接到本地应用服务器守护进程时不可用。

当前文档还区分了本地设置和项目级设置，这意味着开发者在开始导入前，应确切检查文件和配置所处的位置。

结果便是一条实用的经验法则：

一键导入并不意味着无需审查。

真正有价值的资产不是模型订阅

模型基准变化很快。

一个模型可能在某个月份领先，随后便被另一个版本取代。变化慢得多的是开发者周边的工作流。

CLAUDE.md、AGENTS.md、技能、MCP服务器、权限、项目记忆、命令以及积累的对话，会随着时间推移变得更有价值，因为它们编码了开发者实际的工作方式。

这使得可移植性成为竞争问题。

这些配置的可复用性越高，开发者对某一AI编程平台的依赖就越低。

而这把双刃剑也适用于两个方向。

诸如SKILL.md、AGENTS.md以及标准化的MCP定义等开放标准，使工作流更容易从一个工具迁移到另一个工具。帮助OpenAI吸引Claude Code用户的互操作性，最终也可能让这些用户更容易离开Codex。

对开发者而言，实用策略很直接：

尽可能将重要的工作流资产保留为可移植格式，并避免让整个开发过程依赖于某个专有工具。

常见问题

Codex能从Claude Code导入什么？

Codex可以导入受支持的指令、设置、技能、插件、项目文件、最近的聊天、MCP配置、钩子、斜杠命令和子代理。OpenAI的文档还将Claude Code的项目记忆映射到Codex记忆中。

如何将Claude Code导入Codex CLI？

启动本地Codex CLI会话并运行/import。然后选择Claude Code，挑选需要引入的受支持的设置或项目文件及最近的聊天，并审查导入的配置。

Cursor可以导入到Codex吗？

可以。OpenAI当前文档显示，Codex CLI可以从Cursor导入，而ChatGPT桌面应用可以从Claude Code、Claude Cowork以及

Cursor。

导入到 Codex 会删除我的 Claude Code 配置吗？

不会。OpenAI 明确表示，导入不会更改或删除现有的代理设置。导入的配置会被单独带入目标环境。

Codex 可以导入多少条 Claude Code 聊天记录？

Codex CLI 最多可以导入最近 30 天内的 50 条聊天记录。/import 命令在使用时机上也有一定限制，因此最好在普通的本地 CLI 会话中运行。

Claude Code 的技能在 Codex 中会表现完全一致吗？

不一定。技能、钩子、权限、插件和命令模板可能依赖原始工具的行为，因此 OpenAI 建议在依赖导入的设置之前先进行审查。

我可以直接将 Claude Code 会话转移到 Codex 中吗？

OpenAI 的 codex-plugin-cc 提供了 /codex:transfer 命令，可以从 Claude Code 会话创建持久的 Codex 线程。该插件专为在 Codex 中继续 Claude Code 工作而设计。

相关工具

• OpenAI Codex：OpenAI 的编程代理，用于软件开发工作流。
• Codex CLI：在本地使用 Codex 的命令行界面。
• Claude Code：Anthropic 的编程代理，也是本迁移指南中讨论的主要源环境。
• Cursor：受 Codex 导入工作流支持的 AI 驱动代码编辑器。
• OpenAI Codex Plugin for Claude Code：OpenAI 官方插件，用于在 Claude Code 内部使用 Codex。

相关链接

• OpenAI 导入文档：从其他 AI 代理导入设置和近期工作的官方指南。
• Codex CLI 文档：安装和使用 Codex CLI 的官方文档。
• OpenAI Codex Plugin for Claude Code：OpenAI 官方仓库，用于 Claude Code 集成。
• Codex 插件 README：Claude Code 插件的安装和使用说明。
• Claude 数据导出：Anthropic 官方导出 Claude 账户和对话数据的指南。
• OpenAI Developers：OpenAI 的主要开发者文档中心。
• OpenAI Devs on X：源文章引用的 OpenAI 开发者帖子。

总结

OpenAI 当前提供的导入工作流消除了开发者在 Claude Code 或 Cursor 中积累数月配置和上下文后的一大迁移障碍。指令、技能、插件、项目、MCP 配置、记忆和最近的聊天记录现在都可以通过受支持的导入流程移入 Codex。

重要的限制在于，迁移并不等同于完美兼容。权限、钩子、提示词、插件和模型行为在迁移后可能发生变化，因此应在使用前对导入的配置进行审查。

它们成为了生产工作流程的一部分。

最具可移植性的AI编码设置，是让宝贵的指令、技能和项目知识保持独立于任何单一智能体的设置。