你的 Codex 日志可能早已悄悄毁掉你的固态硬盘，却未发出任何警告信号

如果你一直在长期运行的开发机器上使用 OpenAI 的 Codex CLI，那么你的固态硬盘很可能一直在悄悄“大出血”。Codex 诊断日志系统中的一个漏洞正在向本地磁盘写入数百太字节的数据。

一块正在报废的固态硬盘不会发出咔嗒声或摩擦声，而鉴于这个漏洞的严重程度，它可能在不到一年内就把一块普通消费级固态硬盘的终身写入寿命给吃干榨净。所以，如果你一直在使用 Codex，最好去看看你的固态硬盘还撑不撑得住。

你的固态硬盘可能正在被狠狠折腾

过度日志会在你还没察觉到任何异常之前，就已经产生海量的磁盘写入

罪魁祸首并不是 Codex 真正在干的编码活儿。而是 Codex 用来存储反馈和诊断日志的一个本地 SQLite 数据库。默认情况下，日志输出被写死在了最啰嗦的详细级别 TRACE 上，从原始 WebSocket 数据包到文件系统监控事件，什么都要记下来。

数据库文件本身在你的硬盘上看起来从来都不大。Byteiota 报道称，虽然数据库本身任何时候大约只保留 68 万行，但底层 SQLite 的行 ID 早已冲破了 55 亿。这种对不上号的情况，才暴露了真正的问题。

Codex 会插入大量日志行，然后马上又删掉，如此反复不停地折腾，所以屏幕上看到的文件大小一直很小，但底层真正的闪存却在通过所谓的“写入放大”机制承受着实实在在的、永久性的写入损耗。你的硬盘承受了这么大的损害，可记录下来的所有内容中约有 96% 对普通用户来说根本没有任何诊断价值。

更糟的是，开发者用来关闭详细日志记录的标准环境变量 RUST_LOG=warn 在这种情况下压根儿不起作用。SQLite 日志接收器完全绕过了 Rust 通常的日志过滤器，所以没有任何有文档记录的办法能让你自己把日志级别调低。

最终的发现来自 Rui Fan，他是一位开发者，也是 Apache Flink 项目委员会成员，他发现自己的机器存储出了毛病。他意识到自己的主 SSD 在正常使用 Codex 仅仅 21 天里就写入了大约 37 TB 的数据，于是在 2026 年 6 月 14 日提交了 GitHub issue #28224。

按全年算下来，就得到了现在大家都知道的那个每年640TB的数字。作为参照，大多数1TB消费级固态硬盘在其整个使用寿命内的质保耐久度标称约为600太字节写入量（TBW）。仅Codex一项不到一年就能把这个额度写穿，而这还没有考虑操作系统和其他软件还会对同一块硬盘产生多少写入量。

在该问题于Hacker News上拿到438分、引发关注后，OpenAI的ChatGPT和Codex核心产品主管Thibaut Sottiaux公开承认了这一缺陷，并确认修复已经上线。6月22日和23日合并了两个拉取请求：一个是不再记录每一个Responses WebSocket事件，另一个是从持久化日志中剔除了产生大量噪音的内部目标。

这些修复合计砍掉了约85%的不必要写入量。不过这还没彻底解决问题。打补丁后，由于部分事件的TRACE级日志还在开着，据估计Codex在最坏情况下每年仍会写入约96TB。

闪存存储有极限

持续写入会消耗固态硬盘的耐久度，缩短使用寿命，并可能随着时间的推移影响性能

固态硬盘的坏法跟机械硬盘不一样。NAND 闪存单元能承受的写入-擦除循环次数是有限的，用完了就会退化，这就是制造商公布 TBW 额定值的原因。一个 bug 悄悄往你硬盘里写入几百 TB 的垃圾数据，就是在实打实地缩短你硬盘的寿命。而且它干这事的时候，你根本看不到——不会有个臃肿的文件摆在那儿，让你平时翻硬盘或做电脑维护时发现。

如果你习惯让基于代理的开发工具在后台长时间跑着——而这恰恰是 OpenAI 一直在推的用法，Codex 的自主功能和电脑操作功能就是干这个的——那你就是最容易中招的那批人之一。就算你已经更新了 Codex，损害也已经造成了，想恢复只能换硬盘。

想看看自己中招有多深，最好用 smartctl 这类工具把你固态硬盘的 SMART 数据拉出来看看，看看总写入字节数或者已用百分比那几项。固态硬盘制造商也提供免费工具来监控存储和硬盘健康状况，如果你不想盯着终端一行行看，这些工具挺管用的。

如果你还没有更新，请确保 Codex 至少更新到 0.142.x 版本，两个修复都已合并进这个版本。另外，建议直接检查日志目录的大小，而不是依赖文件资源管理器的显示，因为显示出来的数字可能不准。你可以在 macOS 或 Linux 上运行 du -sh 命令，或者看看 .codex/logs_2.sqlite 里有没有过大的 WAL 文件。

如果无法更新，macOS 和 Linux 用户可以停止 Codex，删除现有的日志文件，再给它们做个符号链接，指向 /tmp 下的某个位置，这个目录通常挂载在内存里的 tmpfs 上。

这样一来，写入就完全不会再落到物理硬盘上了，不过重启后会被重置，而且 Windows 用户就没有对应的办法了。

AI 软件也逃不过烂工程

AI 功能再强，也不能拿低效的默认设置当借口，尤其是它们还在悄悄影响用户硬件的时候

Codex 的日志记录缺陷很好地提醒我们，AI 驱动的工具并不自动意味着它经过了良好的工程设计。一个本来帮开发者省时间的工具，差点让一些人赔进去一块新固态硬盘，再算上现在存储市场的价格，修起来既费时间又费钱。

OpenAI 的修复消除了大部分损害，但常驻后台的代理工具爱过度记日志这个老毛病，并没有完全改掉。犯这毛病的助手可不止 Codex 一个，因此如果你每天依赖 AI 编程代理，就把检查磁盘写入和日志膨胀纳入日常维护吧。