这件事最值得从业者留意的地方,不是 OpenAI 又出 bug,而是我们日常检查磁盘的那套习惯完全失效了。du、df、Finder 看的是文件系统逻辑大小,Codex 的 SQLite 日志库一边狂写一边回收空间,文件体积纹丝不动,只有 SMART 计数器能读出物理写入量。报告者 Rui Fan 实测 21 天写入 37 TB,年化 640 TB,而一块 1TB 消费级 SSD 的额定写入寿命通常就 600 TBW。4 月 10 日就有人贴出了 strace 里 pwrite64 刷屏的证据,但每个看到 issue 的人都用 du 扫一眼,觉得文件不大、磁盘没满,就没当回事,直到 6 月 22 日登上 Hacker News 前排才引爆。
根因是日志级别默认设成了 TRACE,连打开系统文件和 WebSocket 原始帧都原封不动记下来,而且 Codex 自己的默认值会绕过用户设的 RUST_LOG 环境变量。0.142.0 合并了修复,报告者反馈能砍掉约 85% 的写入,年化降到 32 TB 左右,回到正常水平。但 Windows 桌面包在修复合并后仍然复现,第三项关键修复还在 0.143.0 里没发布。
正文没披露 OpenAI 内部为什么把默认级别设成 TRACE,也没解释为什么 4 月的报告没被及时升级。600 TBW 是保修值不是硬边界,很多盘超了还能用,截至发稿也没有公开的因这个 bug 实际烧坏硬盘的案例。但这件事提醒我们:本地 agent 常驻后台之后,磁盘写入会变成一个需要主动监控的指标,不能只靠文件大小和剩余空间来判断。