一个命令/import，支持一键搬家，Codex搬空Claude Code
换工具，最贵的不是订阅费
一个AI编程工具用久了，真正有价值的并不是工具本身，而是围绕它积累起来的配置、技能、命令、记忆和工作习惯。
这些东西看起来只是散落在电脑里的文件，实际上已经成为一套个人生产系统。换工具之所以麻烦，不是重新安装一个软件，而是要重新训练一个助手。
所以我认为，Codex推出导入能力，争夺的并不只是Claude Code和Cursor的用户，而是用户已经积累起来的数字家当。
导入的不是文件，而是一套工作方式
按照原文介绍，ChatGPT桌面端可以从设置中的Import入口识别Claude Code、Claude Cowork和Cursor；Codex CLI也提供了相应的导入入口。
可迁移的内容包括指令、设置、技能、插件、MCP服务器、Hooks、子智能体、项目记忆、本地项目和近期会话。用户可以逐项选择，导入只复制内容，不修改原有配置。
其中有些内容只是换一种格式。例如，CLAUDE.md转为AGENTS.md，settings.json转为config.toml，项目记忆转为Memories。
另一些内容则不只是改名。原来的斜杠命令会转成skill，插件中的命令也要随之转换。名称、调用方式和适用范围都可能发生变化。
项目迁移同样容易被误解。Codex接管的是本机已有的项目目录，并不是把整个代码仓库复制到另一个地方。
这说明所谓一键搬家，本质上是一套跨智能体的语义转换系统，而不只是文件复制工具。
会话连续性正在成为产品能力
长会话迁移是一个很实际的问题。旧对话可能已经超过新工具一次能够处理的上下文长度。
原文提到，Codex在导入时会记录会话长度和额度占用。用户第一次继续旧对话时，系统会先压缩前文，再接着回答。
这个细节很重要。迁移功能如果只负责把数据搬过来，却不能让用户继续工作，就只是形式上的兼容。
真正有价值的迁移，必须让上下文可以延续，让用户不必重新解释自己做过什么、为什么这样做。
搬家通道目前主要是单向的
原文梳理的产品演进显示，Codex在几个月内多次扩充导入范围，从设置、技能和聊天，逐步增加到MCP、插件、命令、项目记忆以及Cursor内容。
桌面端还可以持续接收原工具中的新内容，CLI也支持同步已经导入会话的后续变化，并避免重复。
但同步方向主要是从Claude Code、Cursor流向Codex。Codex中的修改不会自动回写，相关文档中也没有对应的统一导出入口。
这和Anthropic的记忆迁移思路有所不同。原文称，Claude既允许从ChatGPT、Gemini导入记忆，也允许把自己的记忆导出用于备份或迁移。
我更看重双向流动。导入降低的是进入成本，导出保障的才是用户选择权。
能搬走配置，带不走原来的执行者
迁移并不等于完全兼容。真正麻烦的地方，恰恰是无法机械转换的部分。
首先是权限模型。Claude Code中的细粒度白名单，与Codex的只读、工作区可写和完全开放三档权限并不对应。迁移时必须重新理解原有规则背后的安全意图。
其次是Hooks。复杂的条件分组和异步处理链找不到完全对等的实现时，就需要重新设计，而不是简单转换。
第三是模型。配置、技能和提示词可以搬到Codex，但执行这些规则的已经从Claude变成GPT。为一个模型反复调校出来的表达方式和任务策略，换一个模型未必仍然有效。
第四是数据边界。原文称，能够迁移的主要是本机保存的会话，网页端对话并不包含在内；CLI导入还存在时间和数量限制。
社区对迁移效果的估计是，大部分配置可以自动转换，但剩下的部分仍需人工检查。权限、MCP登录、Hooks、插件以及带参数和路径的命令模板，都是容易出问题的地方。
因此，一键迁移解决的是初始搬运，不是最终验收。
开放格式正在削弱工具锁定
这场竞争最值得注意的，不是哪一个模型暂时领先，而是哪一种用户资产能够跨工具保存。
模型排名会变化，配置、技能、记忆和历史会话却会持续积累。它们既提高个人效率，也构成平台留住用户的壁垒。
但平台要降低别人用户的迁移成本，就必须打通格式。AGENTS.md、SKILL.md和标准化MCP配置越普及，开发者资产就越容易跨平台流动。
这会形成一个有意思的结果：厂商为了吸引用户而修建迁入通道，同时也在削弱整个行业的封闭性。
对开发者来说，我的判断很明确：不要把自己的核心工作方式押在某一个模型或某一家工具上。
指令、技能、知识和流程应该尽量使用可读、可版本管理、可转换的开放格式。工具可以更换，模型可以更换，真正需要长期掌握在自己手里的，是那套越用越厚的个人生产系统。