“导入 0 条, deferred 27–31 个” Codex 用量不统计
Quick fix
升级后仍复现时需等待分页 rollout 索引修复；临时关闭自动同步可避免反复全量读取，但不会恢复自动统计。
Symptom
Section titled “Symptom”CODEX-SYNC 每轮「导入 0 条, deferred 27–31 个, 扫描 1122 个文件」，deferred 数量随新会话持续增长，跨重启、跨升级不恢复未开启本地路由时，Codex 用量来自会话日志。长会话分页后，续写文件名为 `<线程ID>_<页ID>.jsonl`，但导入器只按文件名末尾的页 ID 建立索引。子代理或分支会话引用根线程时，导入器因此只能找到已经停止增长的首页，误判父 rollout 尚未写到 child fork 时刻，并将子文件永久标记为 deferred，导致 GPT-5.6-Sol 的 `token_count` 未写入用量记录。修复方向是把续写页同时登记到线程本体 UUID，并按分页顺序拼接父时间线后再判断 cutoff；线程中提到已提交 PR #7093，但没有提供其已合并或已发布的确认。
#5870 报告了相同的 GPT-5.6-Sol 缺失现象，但当时没有足够日志确认是否也是分页与 fork 导致；维护者只确认 3.18 之后陆续修复过续聊文件被跳过、正在写入的文件未及时读取等问题，并要求在最新版复测。不同用户还报告 Luna、Terra、review 或 GPT-6-Astra 的显示情况不同，因此问题不是所有模型统一缺失。
先升级到最新版并复测；维护者要求仍只统计部分模型时，记录 cc-switch 版本、系统、`~/.codex/sessions` 下对应会话文件的文件名格式，以及日志中的 `CODEX-SYNC` 行。
若日志持续显示 `导入 0 条` 且 deferred 数不断增长，检查是否存在 `rollout-<时间>-<线程ID>_<页ID>.jsonl` 分页文件，以及子会话的 `forked_from_id` 或 `parent_thread_id`；这可确认是否命中分页 rollout 与 fork 的索引问题。
在正式修复可用前，可关闭 `sessionAutoSyncEnabled` 并重启 cc-switch，避免 deferred 文件每 60 秒被重新全量读取；需要时手动使用“重建 Codex 用量”。此规避措施会停止自动更新，且线程没有确认手动重建能恢复所有缺失记录。
如需尝试恢复已有缺失数据，可使用 #7084 评论提供的恢复脚本：先保持默认 dry-run 核对时间范围和待恢复条目，仅在确认数据库备份及输出无误后使用 `--apply`。该脚本由用户提供，线程中没有成功回报，不能视为维护者确认的正式修复。
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”本页汇总自 2 个真实 issue
- 为什么只看不到 GPT-5.6-Sol，用量页面还能显示 Luna、review、Terra 或 GPT-6-Astra？
- 线程中的实际表现并不一致。已定位的分页与 fork 问题会让特定 rollout 文件永久 deferred，因此只有落在这些文件中的模型用量缺失；其他会话或模型仍可能正常导入。
- 重启 cc-switch 能恢复 GPT-5.6-Sol 用量吗？
- 不能保证。#5870 的报告者重启后没有恢复，#7084 的复现也显示 deferred 状态会跨重启和升级持续存在。
- 不开本地路由时为什么也应该有 Codex 用量？
- 维护者说明，这类用量不是通过本地路由记录，而是从 Codex 会话日志导入；因此未开本地路由本身不应导致主模型记录缺失。
- 有没有临时规避方法？
- 关闭 `sessionAutoSyncEnabled` 并重启可把持续磁盘读取从约 579 MiB/min 降到约 3 MiB/min，但代价是用量看板不再自动更新，需要时只能手动“重建 Codex 用量”。
这是一个非官方社区 wiki，与 cc-switch 作者及项目本身无隶属关系。内容整理自项目公开的 GitHub issues。本站不分发任何软件。