Codex 日志 bug 可能向本地 SSD 写入 TB 级数据

原文 ↗ Hacker News 讨论 ↗

OpenAI 的 Codex 编码助手被发现会在用户机器上生成大量 trace 日志，在某些情况下会向本地 SSD 写入数十甚至数百 GB 数据，并有可能造成磁盘磨损或系统不稳定。评论者认为，这体现了“vibe-coded”的 AI 驱动开发：产品在极少审查、薄弱 QA、过度资源占用以及关键问题修复缓慢或缺失的情况下被快速发布。许多人认为，这削弱了“AI 已经解决软件工程”的说法，反而凸显了在使用 AI 构建开发者工具时，需要更强的测试、保护措施和人类责任承担。

日志 bug 及其影响

  • Codex 的 trace 级日志会持续写入本地 SQLite 数据库，WAL 文件会增长到几十 GB，随着时间推移甚至可能达到 TB 级。
  • 用户报告即使在空闲会话中磁盘也在被疯狂写入；有些人直到使用 iotop 之类的工具，或机器空间耗尽、卡死时，才发现这个问题。
  • 其他 AI 工具（例如 Claude Code、ChatGPT macOS app）也被指出存在类似的重度日志行为，有时可通过将日志符号链接到 tmpfs 来缓解。
  • Codex 仓库中已经提交了修复，预计会在下一个版本中发布。

临时方案和缓解措施

  • 建议的缓解方式包括：
    • 使用 SQLite trigger 忽略对 logs 表的所有插入。
    • 运行 VACUUM FULL 来缩小过大的数据库文件。
    • 通过脚本删除 WAL 文件，或把日志移到基于内存的文件系统。
  • 一些用户因为担心 SSD 磨损，干脆卸载了 Codex 或切换工具。

Vibe coding、slopware 与工程流程

  • 许多人把这个 bug 归因于“vibe coding”：AI 生成的代码只经过极少的人类审查或设计就直接发布。
  • 评论者指出，AI 往往会生成看起来合理、但实际上有细微错误的代码，这让审查更困难，也助长了过度信任。
  • 令人不满的是，一些旗舰级 AI 公司一边宣称要“解决编码”，一边却发布脆弱、难以理解的 Electron/Rust 应用，并带来严重回归。

测试、QA 与责任归属

  • 不少人质疑，为什么基本的 QA 或集成测试没有发现无限日志写入或资源使用失控。
  • 也有人认为，这类 bug 很容易漏掉，除非你明确测试长时间运行场景和资源上限。
  • 还有人强烈反对开发者把责任推给 AI：无论使用什么工具，发布代码的人仍然要为自己发布的代码负责。

用户体验与资源使用

  • 对 Codex、Claude Code、Cursor 以及其他 AI 工具的普遍抱怨包括：CPU/GPU 占用高、内存泄漏、界面卡顿、后台 VM，以及不可配置的行为。
  • 也有少数人表示这些工具对他们来说“够好用”，并且更看重功能而不是打磨程度。

更广泛的 AI 与行业影响

  • 这一事件被用来质疑“AI 已让程序员过时”或“编码问题已经解决”之类的说法。
  • 有些人认为这体现了更广泛的软件质量危机，以及受炒作驱动的管理压力，要求大家“借助 AI 成为 10x 工程师”。
  • 也有人指出，人类同样会发布灾难性的 bug；问题在于流程和激励不足，而不只是 AI 本身。