Codex CLI 0.140.0 这次更新，最值得看的不是又多了一个命令。
而是 Codex 开始认真接住另一批用户：那些已经在 Claude Code 里攒了 CLAUDE.md、skills、hooks、MCP servers、subagents、项目配置和一堆历史会话的人。
以前从一个 Agent 切到另一个 Agent，最麻烦的不是重新安装工具，而是重新训练它理解你的工作流。你要把全局习惯搬过去，把项目规则搬过去，把每个 MCP 重新接一遍，把那些“我已经磨了半个月才顺手”的小配置重新写一遍。
这件事很烦。
Codex 0.140.0 做的事情，就是把这部分摩擦砍掉一大截。
这次更新最狠的一点
根据 OpenAI 在 GitHub 发布的 Codex 0.140.0 release note，这次新增了 /import，可以从 Claude Code 选择性导入 setup、项目配置和最近聊天记录。
OpenAI 的 Import to Codex 官方文档 里也把桌面 App 的路径写得更明确：在 Settings 里点击 Import other agent setup，Codex 会扫描本机可导入的 Claude Code 配置，并引导你完成迁移。
这不是“复制一个配置文件”那么简单。
从官方迁移技能 migrate-to-codex 和 OpenAI Community 里关于 同步 Codex 与 Claude Code 配置 的讨论看，迁移关注的是一整套 Agent 工作台：
| Claude Code 里的东西 | 迁到 Codex 后怎么理解 |
|---|---|
CLAUDE.md | 转成 Codex 项目规则体系里的 AGENTS.md |
| skills / slash commands | 迁到 Codex skills / prompts 相关工作流 |
| hooks | 迁移或转写为 Codex 可执行的自动化约束 |
| MCP servers | 尽量复用已有 MCP 配置 |
| subagents | 转成 Codex 里的 agents / skills / follow-up setup |
| instruction files | 进入 Codex 的全局或项目指令体系 |
| 最近 30 天 session 历史 | 帮 Codex 继承上下文，而不是从零开始，具体以导入界面展示为准 |
这里要特别说一下 CLAUDE.md。
Claude Code 官方文档把 CLAUDE.md 当作项目记忆和指令入口；而 Codex 官方文档把 AGENTS.md 作为项目级 instructions 的核心入口。也就是说，这次迁移不是把名字强行改掉，而是把 Claude Code 的项目记忆，放进 Codex 自己能理解的项目规则系统里。
关于“30 天”这个数字，我这里做一个严谨说明：OpenAI 0.140.0 release note 使用的是 recent chats 这类表述，Verdent 的迁移指南和 TechTimes 的报道则明确写到 last / up to 30 days of session history。实际迁移时，以你本机 Codex 导入界面展示为准。
这就是标题里说的“掀桌子”。
不是说 Claude Code 不能用了，而是 Codex 开始承认：用户已经在别的 Agent 里沉淀了资产。既然这些资产值钱，那就别让用户重新交一遍学费。
为什么这个功能很关键
很多人讨论 AI 编程工具时，喜欢比较“谁写代码更强”。但真正长期使用以后，你会发现另一件事更重要：谁更懂你的工作流。
一个 Agent 好不好用，不只取决于模型本身，还取决于这些东西：
| 维度 | 真实影响 |
|---|---|
| 项目规则 | 它会不会乱改目录、乱加依赖、忘记测试命令 |
| 工具权限 | 它能不能访问 GitHub、浏览器、数据库、内部服务 |
| 自动检查 | 写完文件后能不能触发 lint、typecheck、test |
| 子代理 | 能不能把代码审查、资料核验、测试修复拆给不同角色 |
| 历史上下文 | 它知不知道你前几天为什么这么改 |
| 全局偏好 | 它会不会按照你的表达风格、协作习惯、交付格式工作 |
这些东西不是一天攒出来的。
所以迁移功能的价值不只是“方便”。更准确地说，它降低了换工具的心理成本。你不用一边想试 Codex，一边担心 Claude Code 里那套配置白费了。
社区里也已经有人在写迁移实战。比如 Blake Crosley 的 Claude Code to Codex Migration 就把迁移问题拆成了配置、规则、MCP、命令习惯等部分；Verdent 的 Claude Code vs Codex: Why I Switched 则更偏“为什么切换、切换时关注什么”的视角。
这些文章的共同点是：大家真正关心的不是“我能不能打开 Codex”，而是“我原来的工作流能不能继续跑”。
Codex 0.140.0 这次就是对准了这个问题。
CLI 怎么用：输入 /import
如果你用的是 Codex CLI，升级到 0.140.0 之后，在交互式会话里输入：
/import
然后按界面提示选择要导入的内容。
根据 0.140.0 release note 和 /import 相关 PR，CLI 端的设计重点有几个：
| 动作 | 说明 |
|---|---|
只在你输入 /import 时扫描 | 不会一启动就强行迁移 |
| 可以选择性导入 | setup、项目配置、最近聊天记录可以按需选 |
| 有导入前确认 | 让你知道检测到了什么、要导入什么 |
| 导入后刷新配置 | 让当前 Codex 能看到新配置 |
| 不支持的会话会拒绝 | 比如某些 remote 或 daemon 场景不会假装能迁 |
实际建议是：第一次不要全选。
更稳的方式是先导入 setup 和项目配置，确认 Codex 的行为正常以后，再导入 session 历史。因为历史会话越多，上下文越复杂，最好先确保基础配置没有冲突。
一个比较稳的迁移顺序是：
1. 备份原来的 ~/.codex 和 Claude Code 配置
2. 更新 Codex CLI 到 0.140.0 或更高
3. 进入一个你熟悉的项目
4. 输入 /import
5. 先导入 setup 和 project config
6. 打开 AGENTS.md 检查迁移结果
7. 运行一次 codex doctor 或项目测试命令
8. 再按需要导入最近聊天记录
这里最值得检查的是 AGENTS.md。
如果你之前在 CLAUDE.md 里写了很多项目规则，比如“不要改 generated 目录”“提交前跑 pnpm test”“所有接口类型从 schema 生成”，导入后一定要看一眼这些规则有没有进入 AGENTS.md，有没有被改得太泛。
Agent 迁移最怕的不是没迁完，而是迁过去以后看似完整，实际关键约束丢了。
桌面 App 怎么用：Settings 里点导入
桌面 App 的路径更适合普通用户。
打开 Codex Desktop App，进入：
Settings -> Import other agent setup
然后让 Codex 自动扫描本机的 Claude Code 配置。
这条路径的好处是可视化更强。你不用记命令，也不用先知道 Claude Code 的配置藏在哪。Codex 会帮你识别可迁移内容，再把能自动转换的部分转过去。
如果有些内容不能自动转换，官方文档里提到可以开一个 follow-up conversation，让 AI 引导你手动补齐。
这个设计我觉得很重要。
因为 Claude Code 和 Codex 的能力模型不是完全一一对应的。比如某个 hook 里的 shell 命令可以直接迁，但某个高度定制的 subagent 行为，可能更适合在 Codex 里拆成 skill、agent instructions 或项目规则。强行“自动转换 100%”听起来爽，但风险也大。
更合理的体验应该是：
| 情况 | Codex 应该怎么处理 |
|---|---|
| 能确定等价 | 自动导入 |
| 能部分转换 | 先导入，再提示你检查 |
| 无法确认语义 | 开 follow-up conversation，让 AI 带你补 |
| 有权限风险 | 保留给用户确认，不静默开启 |
这也是我建议优先用桌面 App 跑第一遍迁移的原因。CLI 更快，App 更适合看清楚。
/usage：终于能看到 token 烧到哪了
0.140.0 另一个很实用的更新，是新增了 /usage。
官方 release note 写得很直接：新增 daily、weekly、cumulative 三种 account token activity 视图。对应 PR 里也提到支持：
/usage
/usage daily
/usage weekly
/usage cumulative
这对重度用户很有用。
以前大家用 Agent 经常有一种“电表不透明”的感觉：今天跑了几个大任务、贴了几段日志、让它读了多少文件、到底烧了多少 token，其实没什么直观感知。
现在你至少可以按三个维度看：
| 命令 | 适合看什么 |
|---|---|
/usage daily | 今天是不是被某个任务吃爆了 |
/usage weekly | 这一周主要消耗趋势 |
/usage cumulative | 长期累计 token 活动 |
这不是为了让你焦虑，而是让你做判断。
比如你发现某天 token 异常高，就可以回头看是不是某个超大仓库被重复读了，或者某个任务反复失败导致会话拖得特别长。对团队来说，这类数字也能帮助你判断：哪些 Agent 流程值得沉淀成 skill，哪些大段上下文应该放进文件而不是每次粘贴。
一句话：能看见，才谈得上优化。
@ 统一入口：文件、插件、技能不用分开找
这次还有一个看起来小，但日常体验很明显的改动：输入 @ 默认打开统一 mentions 菜单。
在 0.140.0 release note 里，官方写的是：typing @ now opens the unified mentions menu for files, plugins, and skills by default。
以前这几个入口是分散的。你想引用文件、想叫插件、想用 skill，脑子里要切换不同入口。现在统一到 @，它更像一个“把上下文带进来”的总入口。
日常可以这样理解：
你输入 @ 后想找 | 用途 |
|---|---|
| 文件 | 让 Codex 读取或围绕某个文件工作 |
| 插件 | 调用 GitHub、Gmail、Browser、Data Analytics 等能力 |
| 技能 | 启动某类标准工作流，比如写文章、做数据分析、修 CI |
这个变化背后的方向很明确：Codex 不想让你记很多命令，而是把“我要引用什么能力”统一成一个动作。
对新手尤其友好。你不用先知道某个能力属于文件、插件还是 skill，只要先按 @ 搜。
/goal 增强：大段文本和图片不容易丢了
/goal 也增强了。
0.140.0 release note 里写到，/goal 现在会保留 oversized text、大段粘贴内容和图片附件，包括 remote app-server sessions。几个相关 PR 分别处理了长文本、粘贴文本和图片附件。
这解决的是一个很真实的问题。
有时候你不是让 Agent 做一个小任务，而是要给它一个长期目标，比如：
/goal 帮我把这个项目的支付模块重构完，要求如下：
1. 保留现有 API 行为
2. 先补测试
3. 拆出 provider 层
4. 支持 Stripe 和 Paddle
5. 下面是当前错误日志……
以前如果你贴了很长一段内容，或者把图片、截图也放进 goal，部分信息可能不会被完整保留。现在 Codex 会把超大目标、粘贴文本和图片材料化成附件引用，让后续任务还能读到。
更适合的用法是：
/goal
然后把完整目标、长日志、截图、设计稿说明一次性放进去。
但这里也有一个建议：不要把 /goal 当垃圾桶。
好的 goal 应该像项目 brief，而不是聊天记录合集。你可以按这个结构写：
目标：完成什么
背景：为什么要做
约束：
- 哪些文件不能动
- 哪些行为必须保持兼容
- 哪些命令必须通过
输入材料：
- 日志位置
- 截图说明
- 相关 issue 或 PR
验收标准：
- 测试通过
- 页面行为正确
- 输出总结包含风险点
现在 Codex 能保留大材料，不代表我们应该把上下文写得更乱。恰好相反，越是长任务，越要把 goal 写得像一份小规格说明书。
大仓库和长 session 也更快了
最后一个不那么显眼但很重要的变化，是性能。
0.140.0 release note 里提到，Codex 改进了大仓库和长 session 的响应速度，包括保留 Git 内置文件系统监视器、避免重复读取历史记录、加速 archive lookup、缓存 turn diff rendering。
这类更新不会像 /import 那样有戏剧性，但对重度用户很关键。
AI 编程助手最怕两件事：
| 场景 | 体验问题 |
|---|---|
| 大仓库 | 每次读文件、算 diff、查历史都慢 |
| 长 session | 上下文越来越重，恢复和继续对话越来越慢 |
如果你每天都在 monorepo 里用 Codex，这种优化会比“又多一个酷炫按钮”更实在。
工具是否能长期留在工作流里，靠的不是第一次演示有多惊艳，而是第 100 次打开时还够不够顺。
我建议你怎么升级和迁移
如果你已经在用 Claude Code，而且想试 Codex，我建议不要一上来“全盘切换”。
按这个顺序来：
| 步骤 | 做什么 |
|---|---|
| 第一步 | 更新 Codex 到 0.140.0 或更高 |
| 第二步 | 用桌面 App 跑一次 Import other agent setup |
| 第三步 | 检查 AGENTS.md，确认 CLAUDE.md 里的关键规则迁过来了 |
| 第四步 | 检查 MCP servers、hooks、skills、subagents 是否可用 |
| 第五步 | 在一个非生产分支里跑一次真实任务 |
| 第六步 | 用 /usage 看 token 消耗，用 @ 引入文件/插件/技能 |
| 第七步 | 如果迁移有缺口，开 follow-up conversation 手动补齐 |
如果你是 CLI 重度用户，可以反过来：
1. 在项目里启动 codex
2. 输入 /import
3. 只导入必要配置
4. 检查 AGENTS.md 和 MCP
5. 跑一个小任务验证行为
6. 再导入历史会话
核心原则就一个：先迁配置，再迁历史；先验证行为，再扩大范围。
这次更新说明了什么
我觉得 Codex 0.140.0 的重点，不只是“从 Claude Code 导入”。
更大的信号是：AI 编程工具正在从“单个聊天窗口”变成“可迁移的工作台”。
以前你选择一个 Agent，就像选择一个孤岛。配置在这里，历史在这里，工具链在这里，换工具就要重新开荒。现在 Codex 开始把这些东西当成用户资产来处理：你的 skills 是资产，你的 MCP 是资产，你的项目规则是资产，你的会话历史也是资产。
这对用户是好事。
因为真正的选择权，不是“你可以注册另一个工具”，而是“你可以带着自己的工作流过去”。
所以这次更新我会给一个很直接的评价：Codex 没有只去卷模型回答，而是在卷迁移成本、上下文继承和长期工作台体验。
这比又多一个 demo 更重要。
如果你已经在 Claude Code 里调教出了一套顺手的配置，现在可以试试 Codex 的一键搬家。别急着删旧工具，先把桌子搬过去，看看新房间是不是更顺手。
参考资料
- OpenAI Codex Release：0.140.0
- OpenAI Codex 官方文档：Import to Codex
- OpenAI Codex 官方文档：AGENTS.md
- OpenAI Codex 官方文档：CLI slash commands
- OpenAI Skills 官方仓库：migrate-to-codex
- OpenAI Community：Sync Codex and Claude Code configs, skills, agents, MCP, permissions
- Anthropic Claude Code 官方文档：Memory / CLAUDE.md
- Anthropic Claude Code 官方文档：Hooks
- Blake Crosley：Claude Code to Codex Migration
- Verdent：Claude Code vs Codex: Why I Switched
- TechTimes：OpenAI vs Anthropic Coding War: Free Codex and One-Click Migration
- Alexander Okhlopkov：How I Set Up Claude Code for Maximum Engineering Productivity
- Qiita：Claude CodeからCodex CLIに乗り換えた