Codex 日志把 SSD 写爆：37TB/21 天的排查与自查方法

一位开发者发现 Codex CLI 的 logs_2.sqlite 在 21 天里写入了约 37TB 数据，而文件本身大小几乎不变，常规磁盘检查完全看不出来。问题来自默认开启的 TRACE 日志、RUST_LOG 覆盖失效，以及 SQLite 的 WAL 写入循环。文章给出了版本修复情况和一套自查顺序。

问题有多严重

• 有用户报告本机 21 天累计写入约 37TB，折合每天约 1.7TB；按这个强度年化约 640TB，但这是单机长时间连续运行的极端值，不代表所有用户。
• 关键陷阱是文件大小：logs_2.sqlite 采用有界保留策略，新日志写入、旧日志删除，数据库体积基本稳定，du 和 ls 看不出异常。
• 类比：咖啡馆中午四桌、傍晚还是四桌，桌数说明不了今天来了 8 位还是 800 位客人。

三个原因叠加

• 日志路径默认开到 TRACE 级别，这是 Rust tracing 里最细的等级，日常使用本应是按需开启。
• TRACE 条目占保留日志正文体积约 70.7%，主要来自 WebSocket 处理、OpenTelemetry 相关日志、依赖库日志桥接和客户端传输代码。
• 用户设置 RUST_LOG=warn 并不能完全压住这个 sink：没有显式覆盖的 target 仍走 Codex 内部默认值，于是用户以为降噪了，磁盘写入量却没变。
• SQLite 本身没问题，问题是用一个高频插入、删除、建索引、checkpoint 的写入循环去承接本不该常开的日志级别。

写入被放大的两层机制

• SQLite 侧：事件先进 WAL 文件，之后 checkpoint 回主库，同时删除旧行、更新索引和页，一条逻辑日志可能对应多次文件系统写入。
• SSD 侧：闪存按页写、按块擦，改一小块数据往往要写到新位置、标记旧数据、搬移有效页再擦除整块，即垃圾回收；磨损均衡还会把写入分散到全盘。
• 两者叠加就是写放大，实际物理写入可能高于操作系统记录的请求量。原文没有测出这块盘的具体放大倍数，不要拿猜测的数字当结论。

640TB 到底危不危险

• 消费级 SSD 的耐久度通常以 TBW 标注，1TB 容量常见为几百 TBW，企业盘更高，具体取决于型号、容量、NAND 类型和保修条款。
• 达到标称 TBW 不等于立刻损坏，它更像保修与寿命参考；但一个后台开发工具悄悄吃掉几百 TB 写入预算，仍然值得重视。
• 危险之处在于它既不占满磁盘，也不报错，只是持续消耗寿命。

自查顺序：先升级，再看真实 I/O

• 第一步升级：调查指出 0.142.0 版本大幅降低了日志写入，早期测试约减少 85%；注意 CLI、桌面端、编辑器插件可能各自打包、更新节奏不同，升级一个不等于全部更新。
• 第二步找文件：macOS/Linux 看 ~/.codex/logs_2.sqlite*，Windows PowerShell 看 $env:USERPROFILE\.codex\logs_2.sqlite*，可能同时存在 -wal 和 -shm 文件。
• 第三步看真实写入：Linux 用 pidstat -d 5 观察哪个进程在写盘，并确认该进程是否打开了这个数据库；不要只看文件大小就下结论。
• 最后再查 SSD 自身的累计写入计数器（如 SMART 相关字段），和系统层数据对照。