这次更新 Windows 版 Codex 后，左侧原来的项目突然空了。我重新导入一个项目文件夹，项目虽然重新出现，旧对话却打不开，提示“继续聊天未成功”。
报错里最关键的是这句：
failed to resolve rollout path ... file does not exist我一开始怀疑是某个 ID 对不上，就把截图交给 Codex，让它检查本地记录。检查确认原项目记录和会话文件仍在，问题出在三处：项目列表索引丢了，一条会话的文件位置与索引不一致，还有 20 条旧会话被明确留在“无项目归属”列表里。
备份后逐项修复，Codex 重新读到了 59 个本地项目；当前项目遗漏的 20 条旧会话也恢复了归属。Codex 抽查的旧对话可以正常读取，但没有向旧会话发送新消息，也没有逐条打开所有项目和会话验证。
项目没显示，记录还在
Codex 检查本机数据时发现，数据库里仍保存着原来的项目名称和目录，但桌面侧栏使用的另一份本地索引，只剩下我重新导入的那个项目。
也就是说，项目文件夹没有消失，原项目记录也没有被清空，只是界面用来显示项目的映射不完整了。
这两处记录各有一套内部 ID，需要正确对应。恢复时没有清空数据库，也没有把所有对话批量重建，而是从仍在的项目记录还原侧栏需要的映射。重新打开 Codex 后，应用实际返回了 59 个本地项目。
重新导入是不是制造了这次错误，目前没有足够证据。它确实让同一个目录出现了新、旧两条项目记录，但项目列表消失发生在前，真正阻止旧会话显示的还有另一层显式归属状态。
报错的对话，是文件位置对不上
截图中加载失败的那条对话，索引指向正常会话目录，实际文件却留在归档目录里。文件里的会话 ID 能对上，内容也能正常解析。
Codex 先备份数据库、项目索引和原始会话文件，再把这份文件放回索引指向的位置。移动前后校验一致，之后已经可以读出原来的消息和生成结果。
这里还有一个容易误判的地方：部分旧会话没有普通的 .jsonl 文件，旁边却有同名的 .jsonl.zst。这是压缩后的历史记录，不能只看原文件名不存在，就认定聊天内容被删了。这次检查没有发现批量会话文件丢失。
为什么项目恢复了，旧会话还是不见
项目列表恢复后，我发现当前项目里还是缺少一批旧会话。继续查才发现，有 20 条未归档会话仍被记录在“无项目归属”列表中。
这些会话保存的工作目录其实与当前项目一致，但显式的“无项目归属”状态优先级更高，所以 Codex 不会仅凭目录相同就把它们显示回来。这才是项目已经恢复、旧会话仍然缺失的直接原因。
这次没有重建聊天文件，也没有修改聊天内容。Codex 先备份归属状态，再用应用本身的项目移动功能，把 20 条会话逐条关联到当前项目。修复后，应用返回的项目归属已经正确，抽查两条旧会话也能读取；原来置顶的两条对话没有被打乱。
恢复项目列表，必须等 Codex 完全退出
项目索引会在 Codex 启动时读进内存。应用还在运行时直接改磁盘文件，后续保存状态可能又把旧内容写回来，所以恢复脚本必须在 Codex 完全退出后执行。
这个过程还踩了一个小坑。第一次等待退出的助手是由 Codex 启动的，Codex 一关，它自己也跟着被回收了。后来改成独立任务等待，两小时后又正常超时，没有写入数据。最后我完全退出 Codex，手动运行已经预检过的脚本，项目映射才真正应用成功。
遇到类似情况，可以先检查什么
如果更新后也遇到项目列表空了、旧对话报文件不存在，可以先让 Codex 做只读检查：
先备份本地项目索引和会话数据库，检查原项目记录是否还在、报错会话是否移到了归档目录、是否存在同名压缩历史，以及旧会话是否被标记为无项目归属。确认原因后再修复，不要清空历史或批量重建会话。
关键是先确认数据还在不在，再修复对应关系。具体文件结构和内部字段可能随 Codex 版本变化，我这次的脚本是按这台电脑上的实际记录生成的，不适合直接复制到另一台电脑覆盖。
