搬家只搬对得上的字段
换到 Codex 的第一周，最怕去年攒的 hook、MCP 和插件还在不在。检测会列出一份清单。导入只收下能映射的那一部分。
本页解决的问题
先给结论「搬家只搬对得上的字段」要解决的关键问题是什么？
换到 Codex 的第一周，最怕去年攒的 hook、MCP 和插件还在不在。检测会列出一份清单。导入只收下能映射的那一部分。
跟着交接处走，不要只看 Demo。 系统是否可靠，往往取决于模型、工具、状态、权限和人的交接处。把每次交接都当成可以观察、测试和恢复的地方。
为一个自动化步骤写清输入、负责人、审批和恢复动作。
一次运行成功了，却说不清发生了什么，也无法安全重放。
- 按字符串选择 Cla 或 Cur，对不上就落到 Claude Codemigration_source.rs L59
- 先扫用户级配置，仓库范围不跑插件检测detect/mod.rs L330
- 会话按 30 天和 50 条过滤，太旧的丢掉sessions/common.rs L43
- memory 要源支持，还要单独打开特性开关detect/mod.rs L59
- hook 只留同步 command，prompt 整条跳过hooks_cla.rs L135
- MCP 命令里出现 ${，整台 server 不要mcp.rs L208
- 市场来源只收 git 家族和本地目录，npm 丢掉source_cla.rs L270
- 说明文件改名，产品名按词边界改写成 Codexrewrite.rs L39
- 同步 import 对 Sessions 直接返回成功service.rs L437
- 后台再写 thread，远程插件后装；开关关则拒绝 memoryprocessor.rs L184
有人告诉你会自动从 Claude Code 搬家。你以为是把整个配置目录拷过来。第二天 hook 少了一条，MCP 少了一台，memory 没出现在清单里。少掉的 hook 用了 type: prompt。少掉的 MCP 命令里写了 ${API_KEY}。
再换一个同事。他用的是 Cursor。Codex 能看见他的 skill 和 hook，看不见他的 memory。仓库里的 Cursor 插件配置会被直接丢掉。
搬家 crate 只负责把外部配置读进来。插件怎么跑，在旁边的 core-plugins。源在类型上只有两个变体：Cla 是 Claude Code，Cur 是 Cursor。字符串对不上 cursor，就落到 Claude Code。调用方漏传源，检测会去翻 ~/.claude。
出处：codex-rs/external-agent-migration/src/migration_source.rs 第 51 至 67 行
一次检测最多产出十种条目。每种后面的导入必须给一个去处。字段先过白名单。Codex 认 11 个 hook 事件，Claude Code 发出 27 个。名字对不上的组，整组消失。单条 hook 的 type 默认当 command，对不上就跳过。MCP 的 command 或 url 里出现 ${，整台不要。市场来源只收 github、git、本地目录。file、url、npm、settings 直接丢掉。
出处：codex-rs/external-agent-migration/src/model.rs 第 53 至 64 行 · codex-rs/hooks/src/lib.rs 第 23 至 35 行 · restored-src/src/entrypoints/sdk/coreSchemas.ts 第 355 至 383 行 · codex-rs/external-agent-migration/src/hooks_cla.rs 第 131 至 137 行 · codex-rs/external-agent-migration/src/mcp.rs 第 204 至 210 行 · codex-rs/external-agent-migration/src/source_cla.rs 第 270 至 274 行
然后说明文件要改名。CLAUDE.md 变成 AGENTS.md。产品名按词边界改成 Codex。Cursor 只用大小写敏感的 Cursor，避免把普通英文 cursor 一起改掉。
出处：codex-rs/external-agent-migration/src/rewrite.rs 第 38 至 49 行
导入器的通用形状是白名单加三条出口。对不上的字段丢掉，不要改写成近似物。prompt hook 不会被塞进 command。带占位符的 MCP 不会被瞎展开。换个语言重写，这份表还用得上。
Claude Code 允许仓库 settings 带着启用插件名单，同事克隆之后自动有同一批插件。对 Codex 来说，仓库里的启用名单不能当安装权威。装上去会进用户配置。不可信仓库想在你机器上装可执行内容，这条路要先切断。
检测只在 home 扫插件。注释写死了：仓库控制的 settings 不能当安装权威。Cursor 只要看见仓库根，插件检测直接返回空。导入看见非空工作目录，报 repository-scoped plugin migration is not allowed。
出处：codex-rs/external-agent-migration/src/detect/mod.rs 第 330 至 332 行 · codex-rs/external-agent-migration/src/migration_source.rs 第 116 至 125 行 · codex-rs/external-agent-migration/src/plugins.rs 第 26 至 36 行
本地插件当场装。远程市场推进待装队列。会话也是两截：检测清单里可以有，同步 import() 对 Sessions 直接返回成功，什么都不写。真正写成 Codex thread 的，是 app-server 里的后台任务。调用方先拿到 import_id。
出处：codex-rs/external-agent-migration/src/service.rs 第 437 行 · codex-rs/app-server/src/external_agent_migration/session_importer.rs 第 100 至 111 行
Codex 认市场清单时，按固定相对路径找第一个存在的文件。四条路径里两条是自己的，两条是竞品的。同一套查找同时服务「用户主动加市场」和「从竞品搬市场」。
出处：codex-rs/core-plugins/src/marketplace.rs 第 20 至 25 行
可执行内容的安装权威必须落在用户级。面向任意 git clone 的产品，home-only 更稳。同步先回执、慢活进后台，是长任务接口的通用形状。
换产品最怕把已经改过的新配置盖掉。目标 hooks.json 里已经有内容，整文件替换会把用户手写的 hook 冲掉。
目标 hook 文件非空，整项取消。已有 config.toml 只补缺失键。MCP 同名 server 保留旧的。第一次搬家像填空。第二次再点迁移，多数条目会因为已经有了而不出现。
出处：codex-rs/external-agent-migration/src/hooks_common.rs 第 13 至 19 行
memory 另有一道门。特性开关默认关，阶段是 UnderDevelopment。检测函数不看这个开关，导入前处理器会查。关着就回 external agent memory import is disabled。导入按字节拷贝，不脱敏。
出处：codex-rs/features/src/lib.rs 第 998 至 1003 行 · codex-rs/app-server/src/external_agent_migration/processor.rs 第 180 至 185 行
导入是填空。用户已经写过的文件，搬家碰不得。memory 默认关，是因为另一家 agent 的项目记忆会按明文进盘。
DeepSeek Harness：不搬家，再装一次
DSH 的插件入口是 thin pnpm forwarder。初始化 profile，在 profile 目录里跑 pnpm，再按安装结果调和清单。插件是 npm 包。没有检测 Claude Code，没有导入 Cursor hook。换产品要自己重装。代价是用户税。好处是不用对一家不断加字段的 settings schema 做永久兼容。
已核对apps/cli/src/plugin.ts 第 120 至 133 行 · 2026-08-22
Grok：自建市场，不搬竞品
Grok 从市场根加相对路径拷进自己的安装登记，并写下 provenance。相对路径禁止 ..、绝对路径和盘符。没有 plugin.json 但根上有 SKILL.md 时，它会补一份合成清单。市场对象是一份自己的目录加来源记录。它不读用户在另一家里启用过的插件。
crates/codegen/xai-grok-plugin-marketplace/src/installer.rs 第 36 至 45 行 · 2026-08-22 · Grok · 插件市场的发现与信任
哪些字段会进清单
桌上有四条 Claude Code 资产：PreToolUse 的 type: command hook、同事件的 type: prompt hook、一台 command 含 ${API_KEY} 的 MCP、一条 40 天前的会话。对照上面的白名单，列出检测清单里应出现和不应出现的条目。
再补一问：调用方何时收到 import_id，这条会话何时变成 thread。开关关着的 memory 若被送去导入，会在哪一扇门被挡回来。
「先玩一遍 · 逐字段看搬走还是丢掉」的能力藏在每次交接里
「有人告诉你会自动从 Claude Code 搬家。你以为是把整个配置目录拷过来。第二天 hook 少了一条，MCP 少了一台，memory 没出现在清单里。少掉的 hook 用了 type: prompt 。少掉的 MCP 命令里写了 ${API_KEY}」说明，Agent 的表现不只由模型决定。模型、上下文、工具、状态、权限和人之间的每次交接，都会改变任务能否继续以及出了问题能否恢复。
先写清状态，再增加能力
从「再换一个同事。他用的是 Cursor。Codex 能看见他的 skill 和 hook，看不见他的 memory。仓库里的 Cursor 插件配置会被直接丢掉」出发，可以把流程拆成起始状态、下一步动作、工具返回、状态更新和停止条件。这样调试时找的是第一处丢失信息或权限的位置，而不是笼统地说“模型变笨了”。
- 按字符串选择 Cla 或 Cur，对不上就落到 Claude Code migration_source.rs L59
- 先扫用户级配置，仓库范围不跑插件检测 detect/mod.rs L330
- 会话按 30 天和 50 条过滤，太旧的丢掉 sessions/common.rs L43
成功路径不能代表系统可靠
用「再补一问：调用方何时收到 import_id ，这条会话何时变成 thread。开关关着的 memory 若被送去导入，会在哪一扇门被挡回来」重放一次成功和一次失败，记录每一轮真正传入的上下文、工具结果和负责人；只要第二个人能复述这条链，系统才有可维护性。
从「先玩一遍 · 逐字段看搬走还是丢掉」走到「思路一 · 三条出口：原样、改写、丢掉」
「先玩一遍 · 逐字段看搬走还是丢掉」先把问题落在「一份家当过白名单：原样、改写、搬不了 播放 单步 重置 源 Claude Code Cursor memory 关 开 会话 10 天 40 天 点卡片可移出家当。切源、开关或会话年龄会重跑。Cursor 不支持 memory，仓库里的插件会被丢掉。 检测 映射 重写 导入 原样 0 改写 0 搬不了 0 后台 0 源字段 Codex 落点 逻辑轨迹 · 动画每一步对应源码里的哪一段 按字符串选择 Cla 或 Cur…」上；到了「思路一 · 三条出口：原样、改写、丢掉」，讨论继续推进到「有人告诉你会自动从 Claude Code 搬家。你以为是把整个配置目录拷过来。第二天 hook 少了一条，MCP 少了一台，memory 没出现在清单里。少掉的 hook 用了 type: prompt 。少掉的 MCP 命令里写了 ${API_KEY}」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析 Agent 时，沿着状态、动作、工具结果和下一步的顺序走一遍；每次交接都要能说明信息从哪里来、由谁确认、失败时停在哪里。
- 「先玩一遍 · 逐字段看搬走还是丢掉」：一份家当过白名单：原样、改写、搬不了 播放 单步 重置 源 Claude Code Cursor memory 关 开 会话 10 天 40 天 点卡片可移出家当。切源、开关或会话年龄会重跑。Cursor 不支持 memory，仓库里的插件会被丢掉。 检测 映射 重写 导入 原样 0 改写 0 搬不了 0 后台 0 源字段 Codex 落点 逻辑轨迹 · 动画每一步对应源码里的哪一段 按字符串选择 Cla 或 Cur…
- 「思路一 · 三条出口：原样、改写、丢掉」：有人告诉你会自动从 Claude Code 搬家。你以为是把整个配置目录拷过来。第二天 hook 少了一条，MCP 少了一台，memory 没出现在清单里。少掉的 hook 用了 type: prompt 。少掉的 MCP 命令里写了 ${API_KEY}
- 「最后的要点」：hook 只留同步 command，prompt 整条跳过 hooks_cla.rs L135
最后的「最后的要点」把讨论落到「hook 只留同步 command，prompt 整条跳过 hooks_cla.rs L135」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。