电脑卡死重启后，Codex 的项目为什么全散了

昨天电脑突然卡死，只能强制重启。卡死本身另有一条排查线，我先处理 Codex 这一边。

重启以后，最先看到的现象很像项目丢了。以前放在同一个项目下的对话还找得到，项目目录却不再出现在 Codex 的项目列表里，这些对话也全都散到了普通列表中。

我一开始也不敢判断到底是哪一层出了问题。代码目录可能被删了，聊天记录可能损坏了，Codex 也可能只是丢了自己的索引。于是这次没有直接重建项目，没有移动文件，也没有尝试修复数据库，先做了一遍只读检查。

先看对话数据库

本机的 Codex 状态数据库还能打开，SQLite 完整性检查通过，里面有 322 条线程。对话主体并没有整体消失。

异常集中在项目关联字段。

这三个结果放在一起，基本解释了界面现象。Codex 还保留着对话，却没有可用的项目记录，也没有项目根目录映射，所以只能把对话当作没有项目归属的线程展示。

日志又补上了一个关键证据。至少有 20 条线程曾经以 workspace_kind=project 启动过。它们以前确实使用过项目工作区，后来统一变成了没有 project_id 的状态。

这些记录说明，Codex 曾经把线程放进项目工作区，项目关联是在后面断掉的。

如果项目目录也被删了，数据库结果还不能说明太多，所以我继续检查本地项目和 Git 仓库。

几个主要项目目录都还在，Git 元数据可以正常读取。Codex 自己的一个本地项目工作区也还保留着，大约有 7,754 个文件。目录内容没有出现整体清空的迹象。

这一步把范围缩小了很多。代码和工作区资料仍然存在，远程项目记录也还在。Codex 丢掉的重点是“这个对话属于哪个项目”这层关系。

只看最终状态，很容易把它误判成一次普通的界面刷新。几处异常写入痕迹让结论变得明确。

第一处是全局状态文件的临时文件。它在异常时间点留下了一个 0 字节文件，文件名带有临时写入标记。这个形态通常出现在原子写入还没有完成时，进程或系统就被打断了。

第二处是 Codex 日志里的配置解析错误。在几分钟内，程序反复报告配置文件某个位置缺少等号。进一步检查发现，那个位置附近出现了大量 0x00。配置文件后来恢复成可解析状态，写入中断本身已经有了证据。

第三处更直接。一个主会话的 rollout 文件中间出现了约 19 KB 的全零数据，只剩最后的换行符，前后相邻内容仍然正常。这个文件后面的对话还能继续读，坏掉的那一段却已经无法从当前本地文件中还原。

同一时间段里，Codex 的 app-server 还发生了多次短暂启动和退出，桌面端也出现了版本切换。更新或迁移可能叠加了影响，但现有证据只能把它列为背景因素，不能单独认定它就是根因。

这次排查可以比较有把握地得到几条结论。

把这些证据串起来，最合理的解释是，异常关机打断了 Codex 的状态写入，随后项目关联层没有正确恢复。代码还在，对话大部分也还在，Codex 暂时失去了把它们重新归回项目的依据。

有一块内容需要单独说明。那段被全零覆盖的 rollout 数据，当前本地文件已经没有可读内容。它能不能找回，要看服务端历史、旧备份或其他设备上有没有副本。仅靠现在这份文件，无法把那一段凭空恢复出来。

完整重建所有历史项目关系也做不到。当前没有找到一份非空的旧状态数据库或全局状态备份，无法仅凭现有快照精确还原每一条对话原来属于哪个项目。

以前说“项目还在”，通常只想到代码目录和 Git。对 Codex 这类工具来说，至少还要把对话、项目目录映射、全局状态和会话文件分开看。

代码仓库能证明源文件还在，不能证明 AI 仍然知道这些对话应该放在哪里。

最危险的动作是刚发现列表异常，就立即重建项目、清空缓存或覆盖状态文件。这样做可能把原本还能分析的痕迹一起抹掉。

更稳妥的顺序是先停下写入动作，保留状态数据库、日志和会话文件的副本，再做只读检查。SQLite 完整性、关联字段、日志时间线和文件中的异常区段，都比界面截图更能说明问题。

如果项目规则只存在于 Codex 的项目关联里，关联损坏以后，代码虽然还在，重新接手仍然要花很多时间。AGENTS.md、README、架构说明和关键操作记录应该放在项目目录或私有备份中，让另一个会话能够从文件重新理解项目。

代码有 Git 远端，通常比较容易恢复。Codex 的本地状态、会话索引和项目映射却经常没有第二份副本。它们不适合未经筛选地公开同步，但至少应该有脱敏的状态备份，或者定期保存关键项目关系和恢复说明。

这次故障留下的教训很具体。电脑卡死以后，Codex 的项目列表出现了异常，数据排查显示这是一次状态关联损坏。项目目录还在，代码还在，对话大部分还在，丢失的是把这些东西组织起来的索引。

这也说明 AI 工具的长期可用性不只取决于模型和代码。项目目录、会话记录、关联数据库、恢复说明和备份策略放在一起，才构成真正的工作环境。

以后再遇到类似情况，我会先保留现场，再确认数据层、文件层和关联层分别发生了什么。只要没有证据证明文件真的被删除，就不要把“界面里看不到”直接当成“数据已经不存在”。