CC Switch 会话不见了的六种解释

打开历史会话列表，前几天还在的那一批对话没了——这大概是用 CC Switch 管 Codex 供应商时最容易让人心跳漏一拍的一幕。第一反应通常是找恢复工具、翻回收站、甚至怀疑配置被覆盖了。但按仓库里那份统一会话历史指南的口径，绝大多数「不见了」根本不是数据没了，而是它被分到了另一个抽屉里，而当前这个视角只看得见自己那一格。

分清这两件事很重要：数据丢失要靠备份救，分组错位只需要看懂过滤规则。这篇把仓库文档列出的六类症状拆开，每一类都给出可执行的判定动作、对应的处置和验证方式，最后说清哪些情况说明根本不是这条线上的问题。

这篇的依据是什么

下面的内容全部来自 farion1231/cc-switch 仓库在 v3.20.1 上的快照（commit 3217f725，核对日 2026-08-31）：docs/guides/ 下的统一会话历史指南、src-tauri/src/ 的 Rust 实现，以及 src/i18n/locales/zh.json 里的提示文案。我们只静态读源码与文档，没有编译、没有运行、也没有安装过这个桌面应用，所以文中不会出现任何关于操作过程、面板样子或速度的描述——凡是能写的，都是能在仓库里翻到具体行号的东西。

先搞清楚会话是按什么分组的

Codex 把会话记录写成 .jsonl 文件，文件头部的 session_meta 里带一个 model_provider 标签。续聊列表与历史列表按当前激活的那个标签做精确字符串过滤——不是模糊匹配，不是并集，是逐字相等才显示。

于是就有了两个抽屉：官方登录跑出来的会话带官方那个标签，CC Switch 接管的第三方供应商统一带 custom。这个常量在源码里写死：src-tauri/src/codex_config.rs:18 的 CC_SWITCH_CODEX_MODEL_PROVIDER_ID: &str = "custom"。指南里专门强调了一句：这是 Codex 自身的设计，不是 CC Switch 弄丢了什么。

设置里那个叫「统一 Codex 会话历史」的开关（文案在 zh.json:709，归在「Codex 应用增强」分组下）做的事只有一件——让官方登录也以 custom 标签运行，把两个抽屉合并成一个。认证方式一点没变，变的只是归类标签。 开关的具体实现是往 live config.toml 里注入一段供应商表，注入函数是 codex_config.rs:3388 的 inject_codex_unified_session_bucket()，反向剥离是 :3432 的 strip_codex_unified_session_bucket()。

理解了这一层，六种症状就都有了坐标系。

判定的第一步：数文件，别数标签

在往下对号入座之前，先做一个动作把「真丢了」和「看不见」区分开：去 Codex 的会话目录里数 .jsonl 文件的总数，而不是去数某个标签下有几条。

指南里记了一个很容易吓到人的陷阱：早期版本的 Codex 根本不在 .jsonl 里写 model_provider 字段，所以你用 grep 按标签分桶数出来的条数，会少于文件总数——这是正常的，不代表少掉的那些文件出了问题。判断「有没有丢」的唯一可靠口径是文件总数。

如果文件总数没少，那就是分组问题，往下看这六条。如果文件总数真的少了，那不是本文讨论的范围，得去查备份与文件系统层面的原因。

六种解释，五种是误解

一、开了开关，但没勾迁移

开关打开只影响此后的运行标签，不会自动搬动已经写好的存量会话。要把开启之前那批官方会话一并搬过来，得同时勾上那个「同时迁入现有官方会话历史」的选项（文案在 zh.json:316）。

怎么确认：看开启时是否勾了那一项；再去 ~/.cc-switch/backups/codex-official-history-unify-v1/ 下面找有没有对应时间戳的目录。这个目录名是源码常量，src-tauri/src/codex_history_migration.rs:29 的 OFFICIAL_UNIFY_MIGRATION_NAME 就是它。没有这个目录，说明迁移压根没跑过。

处置：按指南描述的路径重新走一遍带迁移的开启流程。迁移动作本身是三步：先把原文件原样复制进备份目录，再用「写临时文件 → 整体替换」的原子方式只改头部 session_meta 里的那一个字段，最后在同一个事务里同步改索引库的标签。索引库文件名同样是源码常量：src-tauri/src/codex_state_db.rs:18 的 CODEX_STATE_DB_FILENAME = "state_5.sqlite"。指南明写这一整套流程没有任何删除动作。

怎么验证：备份目录里应出现 jsonl/、state/ 与 meta.json 三样东西。

二、跨供应商续旧会话失败——这是唯一的真限制

这一条和上面那五条性质完全不同，它不是误解，是上游的设计边界。

会话记录里存着 encrypted_content 形态的推理密文，而这段密文只有当初生成它的那个后端能解密，上游按设计就不支持跨后端解密。所以你把一个在 A 处生成的旧会话拿到 B 处去续，会直接失败。

值得说清的是丢的是什么：丢的不是数据，是「跨后端解密的能力」。会话里的文字内容随时都能读，.jsonl 文件完好无损。这条限制在设置项的说明文案里也写着（zh.json:710 那段描述的末句）。

怎么确认：症状是「能看见这条会话、点了继续却失败」，而不是「看不见」。这是它和其余五条最干脆的分界线——看不见是分组问题，看得见但续不上才是这一条。

处置：指南给的经验法则很朴素——跨供应商时更适合开新会话。

什么情况说明不是这个原因：如果换回原来那个供应商续聊也失败，那就不是密文归属的问题，得往别处查。

三、迁移被安全地跳过了

注入不是无条件执行的，源码里设了两道拒绝闸，任何一道触发都直接原样返回、什么都不改：

1. config.toml 里已经有显式的 model_provider —— 说明用户自己配了路由，不去覆盖它（codex_config.rs:3393-3395）；
2. 已经存在一个形态对不上的同名供应商表 —— 拒绝注入，否则会把官方流量路由到一个未知后端（:3397-3408）。第二道闸拒绝时会打印一条警告，末尾是「跳过统一会话路由注入以避免激活未知路由」。

形态比对严格到什么程度？比对函数 table_matches_codex_unified_official_provider() 在 codex_config.rs:3365，它拿注入产物那张表当基准逐字段对齐——name = "OpenAI"、requires_openai_auth = true、supports_websockets = true、wire_api = "responses"，只要与注入产物不是完全一致，就算形态不符。

怎么确认：打开 live config.toml，看顶层有没有 model_provider、有没有一个自己手写的同名供应商表。有其一，跳过就是预期行为。

处置：这属于工具主动让路。要合并抽屉，得先把自己的那份配置整理清楚，再决定是否让开关接手。

怎么验证：确认注入生效的标志是 live config.toml 里出现了符合上述形态的那张表。这里有一条不变量值得记住——这段注入只允许存在于 live 配置里，绝不写进数据库存储配置，而且切走时只在形态与注入产物完全一致时才剥离，第三方自己写的同名表原样保留。

四、还原之后，新建的那批会话没回官方

关掉开关并按备份还原之后，有人会发现「开启期间新建的那些会话」仍然留在合并后的抽屉里。这是产品决策，不是遗漏。

指南把会话分成三类来划边界：A 类是开启时迁入的存量官方会话，备份就是账本，可以精确还原；B 类是开启期间新建的，它们不在任何备份里、官方与第三方也无从分辨，因此永不自动搬动；C 类是开启之前的纯第三方历史，绝不触碰。指南对 B 类的措辞很直白：为了不把第三方会话误塞进官方历史，这些新会话一律留在 custom。

怎么确认：对照会话的创建时间与开关开启的时间。落在开启窗口内的就是 B 类。

还原的判据也值得记一下：一条会话要被翻回去，得同时满足两个条件——它在迁移备份记下的那份账本里（当初标签确实是官方的），并且当前仍然是 custom。两条都成立才动。这样既精确，也不会误伤你手动改过的会话。

五、提示「没有可恢复的迁移备份」

对应的文案在 zh.json:713：「当前 Codex 目录没有可恢复的迁移备份」。

怎么确认：还是去看 ~/.cc-switch/backups/codex-official-history-unify-v1/ 下有没有目录。注意还原动作自己也会产生一份备份，落在另一个目录 codex-official-history-unify-restore-v1/ 下（常量在 codex_history_migration.rs:31），两者刻意分开，为的是保持迁移账本目录的纯净——别把这两个目录看混了。

处置：没有账本就没有可精确还原的对象，这时候不该期待自动还原。

六、提示「开关已重新开启，已跳过还原」

文案在 zh.json:714。这一条说明还原动作是被主动跳过的，不是失败了。

源码里，跳过会写进一个 skipped_reason 字段，v3.20.1 中出现的两个取值分别是 codex_history_migration.rs:231 的 live_not_unified 与 :417 的 nothing_to_restore。文档没有给出这两个原因码与两条提示文案的逐条映射，所以这里只并列摆出来、不替它配对。同一个文件的 :1829 有一条对应的幂等回归测试——也就是说「重复触发不产生额外后果」这件事是被测试覆盖的。

还原成功时的文案是另一条（zh.json:711），它会带上还原的会话文件数与索引记录数两个占位符；真正的失败另有一条（zh.json:712）。看清楚落到的是哪一条，比猜发生了什么有用得多。

什么情况说明根本不是这条线上的问题

排查文章最不该省的是这一段：

• 文件总数确实少了——那是文件层面的问题，与标签分组无关，别在开关上打转。
• 看得见但续不上——第二条那种密文归属限制，或者别的运行时错误，总之不是分组问题。
• 压根没开过统一会话历史开关，也没接管过 Codex——那这六条里除了第二条之外都用不上，会话可见性问题得从 Codex 自身的目录与配置查起。
• ~/.cc-switch/backups/ 下两类备份目录一个都没有——说明迁移与还原都没跑过，这条链路上不会有任何东西被改动过。

最后提醒一句分寸：本文引用的所有路径、常量名与文案都是 v3.20.1 快照里的取值，这个项目迭代很快，常量名与文案随版本变动，遇到对不上时以你手上那个版本的仓库内容为准。另外，这条链路会读写 ~/.codex/ 与 ~/.cc-switch/ 下的真实配置与会话数据，属于本机敏感文件，动手之前先自己确认备份目录里确实有东西。

---

本文依据 CC Switch 官方仓库（github.com/farion1231/cc-switch）的 README、docs/ 下的用户手册、 路由指南与发布说明，以及 src/、src-tauri/、tests/ 的源码整理， 核对日 2026-08-31，对应仓库快照 3217f725（仓库内版本号 3.20.1）。 本文内容为仓库源码与文档口径，我们没有安装或运行过这个桌面应用， 因此不涉及界面外观、操作手感与切换速度的任何描述。 文中出现的阈值与默认值均为源码中的默认配置，不构成对实际运行结果的保证。 该项目仍在快速迭代，版本与默认值随时可能变动，请以仓库最新内容为准。 安全相关做法请结合自身环境评估，本文不构成安全方案建议。