Codex 日志 Bug 一年烧写 640TB，OpenAI 旗舰编程工具被指忽视用户硬件寿命

OpenAI 旗下编程工具 Codex 被曝出一个严重的本地日志写入 Bug：默认开启的最高级别调试日志让一块消费级固态硬盘一年内承受约 640TB 写入量，足以直接报废。事件经 GitHub Issue 和 Hacker News 讨论后引发广泛关注，也暴露出当前 AI 编程工具在资源管理上的系统性短板。

640TB 写入量从何而来

报告者在 GitHub Issue #28224 中实测，他的机器连续开机 21 天，主固态硬盘被写掉 37TB，按此推算一年约 640TB，已超过多数消费级固态硬盘 150–600 TBW 的标称寿命。

问题出在 Codex 本地维护的 SQLite 日志库 logs_2.sqlite 上：15 秒内被插入 36211 行，保留行数却始终维持在约 68 万不变，形成「插入-立即删除」的循环写模式。这种写入方式导致硬盘反复擦写同一区域，但文件大小始终只有约 1GB，肉眼很难察觉。

• 自增行 ID 已超过 55 亿，而真正留存行只有约 50 万，两者相差约一万倍。
• 主要噪声来源是文件系统 inotify 事件，例如 ld.so.cache 被重复记录 128764 次。

根因：一行硬编码的 Level::TRACE

Codex 的日志框架基于 Rust 生态的 tracing 库，sink 初始化时调用了 Targets::new().with_default(Level::TRACE)，将全局默认级别硬钉死在最高档。即使用户设置 RUST_LOG 环境变量为 info 或 warn，该路径上的配置也不生效。

按日志类别拆分，TRACE 级别噪声占写入量的 70.7%（约 732.5MB），加上镜像遥测日志（log_only 和 trace_safe）合计占 96%，真正有意义的内容仅约 4%。此外，将 WebSocket 数据包完整落库这一项就占总写入量的一半。

仓库内至少 9 个相关 Issue

报告者梳理 Codex 仓库发现，「日志无界增长」类问题至少有 9 个 Issue，涉及 WAL 狂写、日志文件疯涨、进程空闲时仍持续写盘、Windows 磁盘占用 100% 等多种症状。源头可追溯到 PR #12969，正是它把 SQLite 反馈日志的 sink 按 TRACE 级别接入。

这表明 Codex 的日志与遥测体系从一开始就没有「资源预算」概念。在 AI 编程 Agent 7×24 小时常驻用户本地运行的场景下，磁盘、内存、CPU 的资源开销长期无人约束。

修复进度与争议

6 月 14 日 Issue 上报后，6 月 23 日报告者宣布关闭：三个 PR 已合并或即将合并，据其反馈可减少约 85% 日志写入。

• #29432、#29457 已随 0.142.0 发布，砍掉逐条 WebSocket 日志和噪声目标。
• #29599 停掉另一类冗余日志，需 0.143.0 才上线。

即便全部生效，剩余约 15% 仍对应一年约 96TB 写入，从「一年烧穿硬盘」降为「六年烧穿硬盘」。有开发者认为 trace 日志本就用于调试，并非 Bug，但反对意见指出：用付费用户的 SSD 寿命给厂商的 debug 做免费存储，缺乏明确授权。

不只是 Codex，AI 编程工具的通病

评论区指出 Claude Code 同样存在大量本地调试日志写入问题，有用户被迫将日志目录软链接到 tmpfs 内存盘以保护硬件。两家旗舰 AI 编程工具在同一类问题上翻车，反映出整个赛道对资源管理的忽视。

当 GPU 长期跑满、内存动辄占用 70GB 成为常态，软件资源消耗的膨胀完全依赖硬件性能提升来兜底。Codex 这个 Bug 之所以能潜伏数月，正是因为硬件性能把症状悄悄消化，直到 SSD 寿命提前耗尽才暴露。