近日关于 OpenAI 的一条新闻在开发者社区中炸开了：OpenAI 自家的 Codex CLI 工具被发现了一个「烧硬盘」级别的 bug——它在后台以每秒约 5MB 的速度持续向本地 SSD 写入日志数据，按此速率计算，一年可写入约 640TB，足以在不到一年的时间内耗尽一块普通消费级固态硬盘的全部写入寿命。

这个 bug 最早可以追溯到今年 4 月。GitHub 用户 1996fanrui 在 6 月 14 日通过 issue #28224 详细记录了他的发现：他的机器在 Codex 运行的 21 天内，主硬盘被写入了约 37TB 的数据。经过排查，罪魁祸首锁定在 ~/.codex/logs_2.sqlite 这个 SQLite 数据库文件上。Codex 的日志系统被配置为以 TRACE 级别运行——这是日志等级中最详细的一档，它会记录几乎所有底层事件的诊断信息，从原始的 WebSocket 数据包到 passwd 和 ld.so.cache 等系统文件的打开事件，无一遗漏。

问题的隐蔽之处在于，这个 SQLite 文件并不会膨胀到一个令人警觉的大小。Codex 的日志系统采用的不是追加写入，而是一个持续「写入-删除-再写入」的循环模式，每分钟执行数万次插入和删除操作。这意味着仅从文件管理器里看这个文件的大小，你不会发现任何异常。但在这平静的表象之下，闪存芯片的实际写入量在飞速累积。

更糟糕的是，Codex 完全忽略了 RUST_LOG 这个标准环境变量——也就是用户自始至终没有任何简单的方法来调低日志级别，除非手动去修改源码。据分析，该日志系统的 SQLite sink 是在 PR #12969 中引入的，当时直接将全局日志级别设为了 TRACE，这个配置显然是为内部开发调试设计的，却在没有任何调整的情况下被推送给了所有终端用户。

从存储技术角度看，这个 bug 的破坏力不仅来自写入量大，还来自 SQLite 的 WAL（Write-Ahead Log）机制造成的写入放大效应。每次数据库事务不仅写入主数据库文件，还会写入 WAL 文件和回滚日志，实际的物理写入量远大于数据库文件本身的增量。再加上每分钟数万次的插入-删除循环，闪存转换层（FTL）的垃圾回收和磨损均衡算法也在承受额外的压力。用户即使通过 SMART 工具监测到了写入量异常，也很难第一时间将其归因于 Codex，因为操作系统并不直接显示单个进程对存储硬件的累积写入量。

衡量一下这个写入量的实际意义。一块典型的 1TB 消费级 NVMe SSD 的 TBW（总写入字节数）额定值大约在 600TB 左右。Codex 以 5MB/s 的基线速度写入，峰值可达 16MB/s，一年累计约 640TB。换句话说，如果你每天使用 Codex 进行较长时间的编码工作，你的 SSD 可能在不到一年时间内就被写入寿命耗尽。而 SSD 寿命耗尽的表现不是缓慢降速——它可能在某次写入操作中突然变为只读模式或彻底无法识别，导致数据丢失。

GitHub 上的开发者社区反应迅速而激烈。社区将此描述为「核攻击级别的磁盘写入」，并警告所有重度使用 Codex 的开发者检查自己的硬盘 SMART 数据。一位用户在 issue 评论中写道：「这是一个非常严重的 bug——在 Linux 机器上，如果系统在磁盘已满的状态下重启，不仅会导致登录失败，Codex 在 /goal 模式中还会主动删除磁盘上的文件和文件夹，试图腾出空间。」另一个评论直接表达了挫败感：「WTF，这太荒谬了，请对你们的用户多一点尊重。」

OpenAI 的响应速度在这个案例中倒不算慢。OpenAI 研究员 Vaibhav Srivastav 对外表示该问题已经在新版本中修复，敦促所有用户立即升级。6 月 22 日，两个修复相关的 PR（#29432 和 #29457）被合并到主分支，核心改动是将 SQLite 日志的默认级别从 TRACE 降至更合理的 INFO，据反馈可以减少约 85% 的日志写入量。剩余的写入是否仍在持续损害 SSD 寿命，社区仍在关注。

值得留意的是，类似的 SQLite 稳定性问题在此前的更新日志中曾被提及过多次，但写入速率的核心问题一直未被触及——issue #17320、#24275、#22444 等相关报告从 4 月起就陆续出现，直到 1996fanrui 的 issue #28224 用精确的数值（21 天 37TB）量化了问题的严重性，才引发了足够的公众关注。

在等待官方补丁推送的期间，社区摸索出了一个临时缓解方案：将 ~/.codex/logs_2.sqlite 软链接到 /tmp 目录下。由于 /tmp 在多数 Linux 和 macOS 系统中是挂载在内存上的 tmpfs，写入操作不会影响物理硬盘。这个文件不包含任何用户对话数据，因此在重启时丢失并不会造成任何实际损失。

这个事件也提醒了开发者社区一件更根本的事情：随着 AI 编码助手从辅助工具逐渐演变为日常开发环境的一部分，它们获得的系统权限和数据访问范围也在扩大。一个普通的代码编辑器通常不会以每秒 5MB 的速度向你的硬盘写入日志。但当 AI 编码助手需要读取你的项目文件、监听文件系统变化、建立代码索引、记录 WebSocket 通信时，它实际上已经变成了系统中最活跃的进程之一。尤其在 /goal 模式下，Codex 拥有文件系统的完整读写权限和自主决策能力——一个日志级别配置错误，就足以让一个强大的自动化工具变成硬件杀手。

参考来源：

• Reddit: OpenAI Codex has a bug that could kill your SSD in under a year
• Notebookcheck: OpenAI Codex has a bug that could kill your SSD in under a year
• GitHub Issue #28224: Codex SQLite feedback logs can write ~640 TB/year
• https://x.com/reach_vb/status/2069202270168772997