OpenAI把外部智能体导入流程统一到一套文档后，直接把目标对准了竞品工具里最难迁走的那部分内容：开发者自己在本机攒下来的配置、技能、插件、项目记忆和历史会话。
8 月 11 日，OpenAI更新了外部智能体导入说明。ChatGPT 桌面端设置里新增了 Import，能够识别 Claude Code、Claude Cowork 和 Cursor；在 Codex CLI 中输入 /import，则可以识别 Claude Code 和 Cursor。
按照文档说明，用户勾选后，可一次性导入这些工具留在本机上的配置、技能、插件、项目以及最近 30 天的聊天记录。导入的是副本，OpenAI在文档中写明，这一过程不会修改或删除用户现有的智能体配置。
但这套流程从头到尾没有提供 /export。也就是说，现阶段支持搬进 Codex，不支持从 Codex 搬出。
可导入内容覆盖指令、设置、插件、项目和聊天
OpenAI给出了一份导入映射关系，列出了不同工具配置进入 Codex 后的对应形式。
其中，Claude Code 侧的指令文件主要是 CLAUDE.md，导入后会变成 AGENTS.md；settings.json 会转换为 config.toml，原本 JSON 加 Markdown 的组合形式被收进一个 TOML 文件。
Skills 仍对应 Skills，插件仍对应插件，但插件能否直接使用还要看后续兼容情况。MCP 服务器配置会对应到 Codex 的 MCP 配置，Hooks 对应 Codex hooks，子智能体对应 Codex agents。
用户自己编写的 slash 命令，即把常用流程封装成 /xxx 的那类命令，迁移后不再以命令形式存在，而是统一转成 skill。插件自带命令在安装时也会原地转换。名称、调用方式和适用范围都可能随之变化，这一步更接近改装，而不只是搬迁。
项目记忆方面，Claude Code 的项目记忆会变成 Memories，最近 30 天聊天则进入 ChatGPT chats。至于项目迁移，OpenAI文档的说法是，已有项目文件夹会变成「使用同一文件夹的项目」。这意味着 Codex 接管的是用户本机目录，而不是把整个仓库上传或复制到 OpenAI 侧。
导入项目支持逐项勾选，范围细到指令、设置、技能、插件、项目和聊天，用户可以按需选择。
长会话导入后会先自动压缩再继续对话
在导入历史会话时，OpenAI还处理了一个常见问题：从 Claude Code 迁移过来的旧会话往往很长，Codex未必能一次读完整段上下文。
Codex的做法是，在会话导入时先记录这段对话的长度和所占额度。等用户回到该会话并发送搬家后的第一条消息时，系统会先自动压缩前文，为后续回复腾出空间，再继续接着对话。
按文中描述，用户不需要手动删减上下文，导入后就可以继续聊。
这套导入能力三个月内经历三次扩容
Codex的导入功能并非在 8 月 11 日才突然出现。
最早的 /import 出现在 Codex CLI 0.140.0。当时只支持导入 Claude Code 的设置、技能和聊天记录，Cursor 用户仍需要手动迁移。
6 月 9 日，Codex app 26.608 将导入流程带到桌面端，并加入首次使用引导。
7 月 21 日发布的 CLI 0.145.0 是一次较大扩容，导入范围增加到六个方面：设置、MCP 服务器、插件、会话、命令和项目级记忆。
8 月 7 日的 0.147.0 又补上了 Cursor 技能导入，以及对已导入会话后续变化的同步。
从时间线看，OpenAI在三个月里连续进行了三轮迭代，明显在加快承接 Claude Code 用户配置的能力建设。
同步方向是单向流入 ChatGPT 和 Codex
整套文档里没有把 Codex 配置导出的命令。用户在 Codex 中做出的修改，也不会回写到 Claude Code。
桌面端虽然提供了自动更新开关，用户也可以查看导入历史，但同步方向只有一个：把 Claude Code、Cursor 侧新增的内容持续同步到 ChatGPT 这边。
上游工具继续更新，下游工具继续接收，方向并不对称。
CLI 侧限制更明确。8 月 7 日发布的 Codex CLI 0.147.0 支持两项新增能力：导入由 Cursor 托管的技能，以及同步已导入的 Claude、Cursor 会话后续变化，同时避免生成重复内容。
Anthropic曾提供双向迁移，OpenAI此前也进入过Claude Code内部
这类迁移工具并不是 OpenAI 一家在做。文中提到，Anthropic 在 3 月初上线了记忆迁移工具 Memory Import，目标是让 ChatGPT 和 Gemini 用户把已积累的偏好和上下文导入 Claude。
Anthropic的支持文档同时写明，Claude 的记忆也可以导出，用于备份或迁移，也就是两个方向都开放。
OpenAI则在 3 月 30 日发布了一个 Apache 2.0 开源插件 codex-plugin-cc，让 Codex 能在 Claude Code 内部运行，并把代码审查和任务托管做成对手终端里的 slash 命令。
该插件内置 /codex:transfer，可将当前 Claude Code 会话转换成一条持久的 Codex 线程。插件文档写明，它使用的正是 Codex 的外部智能体会话导入器，与这次导入流程采用同一套转换规则。
从在对手工具内部运行，到直接接收对手用户的本地配置，OpenAI在四个多月里的动作明显升级。
四类内容仍然难以完整迁移
根据社区里做过完整迁移的开发者反馈，大约九成配置可以自动完成格式转换，剩下一成才是最难处理的部分。
第一类是权限。开发者在 Claude Code 中长期手动维护的细粒度白名单，迁移到 Codex 后只能落到三档沙箱权限之一：只读、工作区可写、完全放开。这个过程不是简单改文件名，而是要把原有白名单背后的使用意图重新映射到三种内置权限配置。
第二类是 Hooks。Claude Code 的钩子模型更复杂，支持条件分组和异步处理链，而 Codex 侧没有完全对应的实现。复杂 hook 链进入 Codex 后，往往不是转换，而是重新设计。OpenAI文档也提醒，导入后的 Hooks 行为可能与原来不同，使用前需要重新审查。
第三类是模型本身。前面迁移的是配置和工作流，真正执行这些配置的模型却发生了变化。Codex原生走的是 OpenAI 的 Responses 协议，并不直接支持 Anthropic 模型。换句话说，即便用户把 CLAUDE.md、技能和 MCP 配置全部搬进 Codex，后续执行这些设置的已经是 GPT，而不是 Claude。除非用户自己搭建兼容网关，注册成 model provider，再单独建立 profile 指向该网关，否则这一项没有原生对应方案。
第四类是聊天记录边界。只有本机本地会话可以迁移，claude.ai 网页端对话和 Cursor 网页端对话都无法导入。CLI 侧还有限制：最近 30 天、最多 50 条。
文中还提到，有开发者统计了 Claude Code 的技能字段，一共 18 个字段里只有 6 个属于通用字段，剩下 12 个只有 Claude Code 自己识别。也就是说，能被原样带走的部分只有三分之一。
OpenAI官方还列出了导入后的复查清单，包括技能和智能体权限、需要重新登录的 MCP 服务器、行为可能变化的 Hooks、需要手动跟进的插件，以及带参数和文件路径的命令模板。
因此，这套流程并不是点一下就结束，而是「一键导入后，再手动检查半小时」。
OpenAI与Anthropic争夺的重点正在转向用户本地资产
文中认为，模型排名和跑分变化很快，但开发者在本机积累下来的配置、记忆、技能和历史会话不会随着版本更替自动消失，这些内容会持续沉淀。
这部分家当既是开发者自己的资产，也是工具厂商留住用户的重要壁垒。OpenAI这次强化导入能力，目标就是把竞争对手的用户迁移成本压低，把原本锁在对方产品内的本地资产接入 Codex。
不过，格式一旦被打通，锁定效应也会变弱。文中点到的 SKILL.md、AGENTS.md 和标准 MCP 定义，正在形成事实上的通用格式。格式越通用，厂商越难只靠配置体系长期锁住用户。
对开发者来说，文中给出的结论很直接：与其把资产押在单一工具上，不如优先使用可迁移的格式。
本文来自微信公众号「新智元」，作者为「ASI启示录」；MarsBit进行了转载。