迁移环境这种事，最讨厌的地方不是文件复制。
文件复制通常有办法。真正麻烦的是那些藏在状态里的路径：会话记录里的工作目录、项目提示里的旧路径、索引文件里的引用、某个状态数据库里的 workspace hint。你看不到它，但它会让新机器上的 Codex 认不出旧项目。
我从 Windows 迁到 Mac 时，就遇到了这个问题。
旧路径是类似这样的：
E:\codexwork\llmwiki
E:\codexwork\RsvP
E:\codexwork\learnagent
E:\codexwork\inte_design新路径变成：
/Users/allen/codexworkspace/llmwiki
/Users/allen/codexworkspace/RsvP
/Users/allen/codexworkspace/learnagent
/Users/allen/codexworkspace/inte_design表面看只是换个路径，实际不是。Codex 里的会话、项目提示和状态文件都可能还记着 Windows 路径。
我当时让 Codex 按什么顺序查
第一步，先列项目。那次重点不是所有文件，而是几个 Codex 旧工程：inte_design、learnagent、llmwiki、RsvP。先确认它们在 Mac 上对应的新目录，不然脚本没有映射目标。
第二步，找旧路径出现在哪里。Codex 要查 session index、global state、workspace hints 和历史会话材料，确认哪些地方还写着 E:\codexwork。这里不能只搜一种字符串，因为 Windows 路径有单反斜杠、双反斜杠和 JSON 转义几种样子。
第三步，先备份。那次留下了迁移前的 session index、state sqlite、global state 和 sessions 备份包。环境修复不是写文章，错了可能影响整个工作区，所以备份必须在修改前。
第四步，写路径映射脚本。脚本把旧路径逐一映射成新路径，比如把 E:\\codexwork\\llmwiki 和 E:\codexwork\llmwiki 都改到 /Users/allen/codexworkspace/llmwiki。这一步的重点不是代码复杂，而是映射要全。
第五步，重启和验证。修完以后还要看 Codex 是否能重新识别工程，旧会话是否能回到正确目录。迁移不是脚本跑完就算完，能继续工作才算完。
这套顺序有点笨，但笨得可靠。
先列清单，再查状态，再备份，再改，再验。
这类任务不能靠拍脑袋
我让 Codex 做的第一件事，是先完整检查，不急着改。
它需要找出哪些地方还引用旧路径，哪些文件可能影响会话列表，哪些状态需要备份，哪些改动会影响后续恢复。那次材料里保留了迁移前备份，包括 session index、state sqlite、global state 和 sessions 备份包。
这个顺序很重要：
先定位
再备份
再建立路径映射
再写脚本修复
最后验证项目是否能重新出现环境迁移最怕一边改一边猜。猜错了，旧状态也没了，就只能从头建。
Codex 在这里像一个排障工程师
它不是简单告诉我“重启试试”。
它会把问题拆成几层：
- 文件层：项目文件有没有在新路径下。
- 会话层：历史 session 是否还指向旧 workspace。
- 状态层：全局状态里是否记录了 workspace hint。
- 索引层：会话列表是否能通过新路径被识别。
- 回滚层：修改前是否有备份。
然后再用脚本做路径替换。比如把 E:\\codexwork\\llmwiki、E:\codexwork\llmwiki 这类写法都映射到 Mac 路径，避免只修了一种转义形式。
这件事很小，但它让我看到 Codex 一个很实用的用法：处理跨机器、跨系统、跨路径的“状态修复”。
这类问题人当然也能查。只是人查起来很烦，因为它不是一个清晰的 bug，而是一堆状态碎片互相咬住。Codex 的优势是它有耐心按层扫。
迁移也需要文档化
这次迁移最后给我留下一个提醒：不要只把项目当成代码目录。
真正的工作环境还包括：
- 项目目录
- 会话记录
- 全局状态
- 本地技能
- 项目规约
- 工作区路径提示
以后再迁移，最好的方式不是“先复制再说”，而是先生成一份迁移清单，把哪些东西要迁、哪些只读、哪些必须备份写清楚。
Codex 很适合做这个。
它不怕琐碎。恰好环境迁移最需要的，就是把琐碎的东西一项项捡起来。