Codex 会话丢失事件完整复盘（2026.08.10）

关联主题:: Codex会话（2026.08.09）
同级:: 2026-08-10_星期一
下一级::

这是一次从”一个简单想法”滚成”折腾一整晚、烧掉 20% 额度”的完整事件复盘。前半段是踩坑流水账，后半段是真正的根因与教训。技术细节已在 Codex会话丢失与恢复实战（2026.08.09） 里写全，本文聚焦决策路径和本可避免的损失。

一、事件时间线

起因：一条 X 帖子

在 X 看到一条帖子（AdrianPunk115），里面有个提示词可以生成图片。想着在 Codex 里试试，结果怎么生成都是报错。

第一阶段：死磕生图报错

• 研究半天，逐个排查：提示词格式？模型不支持？插件没开？
• 全部无果——问题根本不在这些地方，但我不知道，白白消耗时间。

第二阶段：怀疑 CC Switch，切官方订阅

• 终于怀疑是 CC Switch（第三方路由代理）影响了图片生成能力；
• 关闭 CC Switch，切回官方订阅直接用 Codex；
• 结果：
  1. ✅ 图片可以正常生成了（证实 CC Switch 确实是生图障碍）；
  2. ❌ 左侧历史对话全部不见了（新问题出现）。

第三阶段：AI 自救失败，烧掉 20% 额度

• 开启 Luna 模型，让它想办法恢复对话——搞不定；
• 又开 SOL 大模型继续解决——还是搞不定，烧掉约 20% 额度；
• 心累，决定切回 CC Switch 看看。

第四阶段：切回 CC Switch，会话依然不见

• 切回 CC Switch，打开 Codex，会话还是没回来；
• 继续让 AI 修复，依然搞不定。

第五阶段：时间机器自救失败

• 想起有时间机器备份，尝试恢复 ChatGPT、CC Switch 相关文件；
• 都解决不掉——因为只恢复了 sessions/ 一个文件夹（正文文件），没恢复”目录页”（数据库/索引/全局状态）。

第六阶段：WorkBuddy 逐层定位，完整恢复

最终打开 WorkBuddy，一步步排查，才找到真正的根因并完整恢复（详见下方”根因”和 Codex会话丢失与恢复实战（2026.08.09））。

二、为什么 AI 自救（Luna/SOL）搞不定

这个值得单独复盘——不是模型能力不行，而是方向错了：

1. 让 Codex 自己修自己：Codex 在修复过程中本身就在写数据库、改 config，每次运行都可能覆盖掉正在诊断的现场（运行中的 Codex 每几分钟重写一次 state_5.sqlite / global-state）；
2. 只盯着 sessions/ 文件夹：整个排障思路都被”会话文件在 ~/.codex/sessions/”带偏，不知道界面真正读的是 state_5.sqlite 的 threads 表；
3. 反复切换路由放大混乱：官方订阅 ↔ CC Switch 之间反复横跳，每次都触发云同步，往 threads 表灌入 openai provider 会话，把本来就错的目录冲得更乱；
4. 没有先备份再动手：每次”修复”都在没有快照的情况下改数据，越修越乱，最后只能依赖时间机器兜底。

消耗 20% 额度的本质：让大模型在一个没有”正确诊断框架”的问题上反复尝试——它每次都能找到新的表面原因，但根因（provider 标记过滤 + 多文件一致性）始终没被触及。

三、真正的根因（技术层面）

1. Codex 会话由 5 个组件协同：正文文件（sessions/年/月/日/*.jsonl）+ 会话目录数据库（state_5.sqlite 的 threads 表）+ 索引（session_index.jsonl）+ 全局状态（.codex-global-state.json）+ 归档（archived_sessions/）。只恢复其中一个 = 白恢复；
2. 桌面版读的是 state_5.sqlite，不是 CLI 的 sqlite/codex-dev.db——最容易踩的坑；
3. Codex 侧边栏按 threads.model_provider 过滤会话：切到官方订阅（openai）后，历史会话的 provider 标记还停留在 cc-switch-official / custom，界面把它们全部藏起来了——数据一条没丢，只是”看不见”；
4. 云同步污染：官方路由会从云端灌入 openai provider 会话，进一步扰乱目录。

一句话：会话不是丢了，是”目录页”和当前路由对不上 + 目录页本身被云同步冲乱。

四、损失盘点

损失项	明细
时间	从下午折腾到深夜，几乎一整天
额度	约 20%（Luna + SOL 反复尝试）
情绪	心累、挫败感（“给我整心累了”）
数据	一度看似全丢（最终全部找回）

真正保住的：所有会话正文文件（sessions/）从头到尾一个都没丢——丢的只是”目录页”。这决定了结局是可恢复的。

五、本可避免的教训

1. 切换路由前先备份（30 秒的事）：备份 state_5.sqlite + session_index.jsonl + .codex-global-state.json + archived_sessions/ 四个文件，一条命令；
2. 怀疑代理先验证再切：CC Switch 生图报错时，可以先查它的代理日志/能力，而不是先切换再面对新问题；
3. 让 AI 修环境类问题前，先给它正确的诊断框架：不是让它”恢复对话”，而是告诉它”去查 state_5.sqlite 的 threads 表 provider 分布、对比 config 的 model_provider”；
4. 运行中的 Codex 会覆盖现场：任何修复前先完全退出应用，否则越修越乱；
5. 时间机器恢复要恢复”整套”：不是只恢复 sessions/，而是恢复数据库+索引+全局状态+归档；
6. 止损意识：同一个问题换两个大模型各试一轮仍无进展时，应该停下来换思路（比如直接查文件/数据库），而不是继续烧额度。

六、WorkBuddy 为什么能解决

对比 AI 自救与 WorkBuddy 排障，本质差异是诊断路径：

• AI 自救：在 Codex 内部”对话式”修复 → 看不见数据库/文件全貌 → 反复试错 → 越修越乱；
• WorkBuddy：直接读 state_5.sqlite 表结构、对比 Time Machine 快照、定位 provider 过滤机制 → 一次定位根因 → 分步恢复（8/8 快照 → 8/9 15:05 快照找回当天会话）→ 验证三连。

结论：环境/数据类故障，优先用”能直接看到文件和数据库”的工具排查，而不是在出问题的应用内部让 AI 猜。

六点五、最终解法（完整版，2026.08.10 补充）

复盘完成后问题并未一次终结：会话列表恢复后，仍有一部分置顶会话打不开，报错 Model provider 'cc-switch-official' not found。这逼出了最深层的一层根因，也才是完整的解法：

最深层根因：Codex 打开会话读的是正文文件，不是数据库

Codex 打开某条会话时，读取的是 rollout 正文文件第一行 session_meta 里的 model_provider 字段，而不是 state_5.sqlite 数据库里的标记。扫描发现 609 个正文文件中 600 个记录的还是旧 provider（custom 543 + cc-switch-official 139）——之前只改了数据库标记，Codex 启动时又按正文文件把标记写回旧值（数据库行数 688→690 的变化就是它在重写）。

完整解法（三步）

1. 批量修改正文文件：把 sessions/ 与 archived_sessions/ 里所有 rollout 文件第一行的 session_meta.model_provider 统一改为 openai（修改前先把原值记录到备份文件，可回滚）；
2. 同步数据库：把 state_5.sqlite 的 threads.model_provider 也统一为 openai，删除 WAL/SHM 残留；
3. config.toml 双保险：保留 cc-switch-official / custom 两个旧 provider 定义，但 base_url 指向官方（空字符串）、认证走订阅账号——即使某个文件漏改，也能按名字找到定义并正常打开，且流量仍全部走官方。

# 核心：正文文件第一行的 provider 统一为 openai（sessions + archived_sessions 共约 690 个文件）
# 修改前先记录每个文件的原始 provider 值到日志，便于回滚
# 然后：sqlite3 state_5.sqlite "UPDATE threads SET model_provider='openai' WHERE model_provider IN ('cc-switch-official','custom');"
# 最后：rm -f state_5.sqlite-wal state_5.sqlite-shm

两条无法恢复的置顶

有 2 条置顶会话（标题都是”你好”，7月19-20日）在任何备份中都没有正文文件——它们是 ChatGPT 云端同步会话，本地从未有过文件。这类会话无法本地恢复，只能取消置顶或删除。

验证结果

数据库 690 条 + 正文文件 691 个，provider 全部统一为 openai；置顶会话全部可打开、可继续对话，报错消失。

六点六、外部工具复核：codex-provider-sync

当天 X 上的另一条经验帖（原帖）给出了
一个专门解决这个问题的开源项目：Dailin521/codex-provider-sync。
它的价值在于把本次手工排障中分散的动作收成一个有备份和事务保护的流程：同步 rollout 正文里的
Provider/model、SQLite 线程记录，以及 user-event、cwd、workspace root 等项目可见性 metadata。

这比“只执行一条 SQL”更完整，也比让出问题的 Codex 自己猜更适合环境类故障。它会先做托管备份，
提供 status、sync、restore、watch，还会报告实际 SQLite 路径和首屏/项目排名诊断。若当时先
完全退出应用、运行 codex-provider status，再执行 codex-provider sync，很可能能减少手工查库和
反复让 Luna/SOL 试错的时间与额度。

但它不是 Time Machine 的替代品：它不能恢复本地从未存在的云端会话正文，也不负责登录、认证、账号
切换；跨 Provider/account 的 encrypted_content 仍可能只能恢复列表可见性，不能保证继续对话。

我已按 v0.4.1 稳定版本全局安装，并只读运行过 codex-provider status：当前 Provider 为 openai，
活动/归档 rollout 均已对齐，工具另外发现 691 条 SQLite user-event flags 待修复。本次没有直接运行
sync，因此没有再次改写当前会话数据；以后应把它作为“切换后先诊断、确认后同步”的标准工具。

七、关联

• 技术细节与完整恢复命令：Codex会话丢失与恢复实战（2026.08.09）
• 概念卡：Codex会话（2026.08.09）、Codex（AI工作台）（2026.08.08）
• 索引：问题索引、方法索引
• 运行档案：Codex 会话恢复运行档案
• 外部工具：codex-provider-sync（Provider 元数据同步与托管恢复）。