Codex 日志写爆磁盘怎么办：SQLite 反馈库与 SSD 寿命排查
Codex 的 ~/.codex/logs_2.sqlite 会在高强度使用时持续写入，用户复现约 21 天写 37TB、年化约 640TB。本文讲现象、升级修复、临时阻断插入和日常监控。
高强度用 Codex 几天后，本机 SSD 写入量异常飙升，不一定是模型下载或缓存膨胀，更常见的是本地反馈日志库在不停 churn。GitHub 议题 #28224 给出的量级是：约 21 天写入约 37TB，外推年化约 640TB——对 1TB 消费级盘、标称 TBW 约 600 的用户来说，等于一年左右写穿保修寿命。
先确认是不是 Codex 在写盘
先看进程与文件，不要直接格式化或换盘。
- 打开活动监视器 /
iotop/fs_usage，看是否有codex相关进程持续写盘。 - 检查这些路径是否存在且体积或 WAL 在涨：
~/.codex/logs_2.sqlite~/.codex/logs_2.sqlite-wal~/.codex/logs_2.sqlite-shm
- 用
sqlite3看保留行数与 AUTOINCREMENT 计数差距。议题里的典型信号是：文件大约 1.2GiB、保留约 50 万行，但 row id 已冲到几十亿——说明历史插入远多于当前保留，写放大来自不断插入再裁剪。
如果磁盘写入飙升但 logs_2.sqlite 几乎不动，再查网络缓存、索引重建或其他工具，别把锅全甩给 Codex。
和本站另一篇 Claude Code 日志膨胀清理 不同：那里是 session 文本日志变大；这里是 SQLite 反馈库的高频插入/WAL，文件大小可能看起来“还行”，但 SSD 累计写入已经很高。
为什么文件不大也会写爆 SSD
议题里的 level 分布显示 TRACE 可占保留内容七成以上。流式事件、工具调用细节被持续写入，再经 WAL、checkpoint、页重写，设备层写放大会再乘一截。
你看到的是“库文件 1GB 上下”，SSD 控制器统计的是“累计写入几十 TB”。排查时以系统级写入寿命计数（macOS 可用 smartctl / 厂商工具，Linux 看 SMART 的 Total_LBAs_Written）为准，不要只看文件体积。
官方修复与版本门槛
2026-06-23 议题作者关闭问题，称三支 PR 合并后可避免约 85% 日志写入：
优先动作：升级 Codex CLI 到包含上述修复的版本，再观察 24–48 小时写入曲线。仍异常再走临时阻断。选型与入口可参考 Codex CLI 是什么。
临时阻断：禁止继续插入日志
社区给出的应急方案（升级前或升级后仍异常时）：
- 完全退出 Codex。
- 执行：
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS
block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE);
END;"
效果：后续 INSERT 被忽略，写盘压力立刻下降。代价是本地反馈/诊断数据不再累积——排查完官方问题后，可删掉该 trigger 或接受“无本地反馈库”的状态。
不要在 Codex 运行中对同一库做破坏性操作；先退出再改。
日常监控清单
- 每周看一次 SSD 累计写入增量，对比升级前后。
- 重度会话后扫一眼
~/.codex/下 sqlite 与 wal 体积。 - 若必须开 TRACE 级诊断，限时开启，用完降回默认。
- 同时开多实例时，确认不是多个进程抢写同一库。
遇到 429 限流时优先看配额与并发，见 Codex CLI 429 排查，别和写盘问题混为一谈。
常见问题
升级到 0.142 后还要不要挂 block_log_inserts？
多数情况不需要。先升级观察写入；只有写入仍异常或你暂时无法升级时，再挂 trigger。长期挂着等于主动放弃本地反馈日志。
直接删 logs_2.sqlite 可以吗？
可以，但先退出 Codex。删除会丢掉历史反馈行；若 trigger 还在，新库重建后可能仍被阻断插入。更稳妥是升级 + 观察，而不是反复删库。
这和“一个月吃掉 150GB 流量”是一回事吗？
不一定。写盘是本地 SQLite/WAL；流量是网络上下行。两者可能同时出现，但排查路径不同：一个看磁盘寿命计数，一个看网卡与代理日志。