谁能想到，天天把AGI挂在嘴边的OpenAI，能在自家旗舰编程工具上栽在一个低级bug上——最近GitHub上编号#28224的issue直接把Codex骂上了Hacker News头条：这个工具正在后台偷偷狂写日志，用不了一年就能把你的固态硬盘直接写报废。

21天写37TB，你的SSD正在被悄悄磨穿

提交issue的开发者做了实测：自己的电脑连续开机21天，主固态硬盘就被硬生生写掉37TB，按这个速度折算，年写入量高达640TB。 要知道主流消费级1TB固态硬盘的标称总写入寿命（TBW）也就150-600TB，普通用户正常用能用十几年，搁Codex这，一年就能把硬盘寿命直接造完。 更鸡贼的是，这个bug隐蔽性极强：你打开日志文件夹看，存反馈日志的SQLite文件永远只有1.2GB大小，看起来一切正常；但数据库的自增行ID已经冲到了55亿，实际留在库里的日志才50万行出头，两者差了整整一万倍。 固态硬盘的损耗是只认累计写入量的，不管你写完删不删，只要数据落到闪存上，磨损就实实在在产生了。也就是说，这55亿行日志哪怕写完就删，硬盘也实打实扛下了所有写入量，根本找不回寿命。更夸张的是这些写进去的内容，9成以上都是开发者根本不会看的调试噪声，光逐字记录WebSocket数据包这一项，就占了总写入的一半。 这事传到Hacker News之后直接引发了开发者群体的怒火，一条高赞评论直接给Codex定了性：这就是“劣质软件（slopware）”最臭名昭著的例子之一。

有Mac用户吐槽，自己电脑上只要不把Codex窗口最小化，那个加载转圈的等待动画就能吃满100%GPU，90%等模型响应的时间里电脑风扇都在狂转，根本不敢拔电源用电池模式。还有网友无奈表示：“这问题都存在快半年了，我想自己动手修，结果发现它桌面端是闭源的。”评论区一句神吐槽戳中笑点：“代码审查怎么没拦住这么明显的错误？哦对了……@codex 麻烦自己审查一下这个bug。”

1GB文件写出640TB，bug根因离谱到好笑

为什么一个只有1GB大小的日志文件，一年能攒出640TB的写入量？ Codex玩了一套“插入即删除”的操作：它本地维护的日志库，每15秒就要插入36211条新日志，插完立刻删掉旧日志，让数据库的总行数一直维持在68万左右不变，文件大小自然不会涨。再加上SQLite本身的WAL预写日志机制，每一次插入删除都要走写预写日志、更新索引、检查点回写全流程，等于同一块存储区域被反复擦写几万次。打个比方：一本100页的笔记本，你每天把整本书内容擦掉重写上千遍，一年下来本子还是100页，但纸早就磨穿了。 这也是这个bug能藏好几个月的原因：它不占磁盘空间，不卡界面，普通用户根本察觉不到异常，只有去读硬盘的SMART健康计数，才能看到写入量在悄无声息地疯涨。 而造成这一切的根因，简单到让人无语：Codex的SQLite日志模块初始化时，直接把默认日志等级硬编码成了最啰嗦、最详细的TRACE级——这是给开发者调试用的最高日志等级，什么鸡毛蒜皮的操作都会记下来。就算用户手动设置RUST_LOG环境变量，想把日志等级调低甚至关掉也没用，这行硬编码配置直接绕开了用户设置，后台照样闷头狂写。 统计显示，留存下来的日志里，70.7%都是毫无价值的TRACE级噪声，加上两路重复的遥测镜像日志，96%的写入都是完全没用的冗余内容，只有4%是真正有意义的日志。

修了，但只修了个寂寞

翻一下Codex的GitHub仓库就会发现，这根本不是第一次出现同类问题：类似“日志无限制增长狂写硬盘”的issue，至少已经有9个。 从早期的WAL文件无限膨胀不释放空间、进程空闲时也狂写盘、Windows下磁盘占用100%，到一个4KB的小数据库被写到每秒11MB写入速度，最早的相关问题PR能追溯到版本初期——等于从Codex发布开始，这套日志系统就没有做过资源占用限制，全靠用户的硬件性能兜底。 从今年4月开始就有用户陆续反馈这个问题，前后拖了两个多月，直到开发者把实测数据甩出来、帖子顶上Hacker News头条，官方才终于出面合并修复补丁。 根据提交issue的开发者更新，目前官方合入的三个PR大概能减少85%的日志写入：其中两个补丁已经随0.142.0版本上线，砍掉了逐包记录WebSocket日志的逻辑、过滤了大部分噪声日志，剩下一个停掉冗余桥接日志的补丁，还要等0.143.0版本才会推送。

就算三个补丁全部实装，Codex一年还是要产生约96TB的写入量，只是从“一年写废一块硬盘”变成“六年写废一块硬盘”，根本没从根源上解决问题。

【编辑观察】 这件事最让人不舒服的点在于：厂商把用户自掏腰包买的硬盘，当成了自己免费的调试日志存储。用户既没有同意过后台写这么多日志，也从这些日志里得不到任何好处，平白无故承担硬件寿命的损耗。 而且犯这毛病的还不止Codex一家，评论区已经有用户爆料，Claude Code也存在同类猛写调试日志的问题，逼得不少开发者把日志目录软链到内存盘，给SSD续命。 这两年AI工具卷模型能力、卷上下文长度、卷生成速度卷得飞起，却很少有人关心这些7×24小时常驻用户电脑的工具，到底占了多少内存、吃了多少GPU、写了多少硬盘。以前软件写得烂，当场就会卡顿崩溃，当天就能被修好；现在硬件性能越来越强，这些烂代码带来的损耗被性能兜住了，用户只会觉得“电脑怎么越用越慢”，根本想不到是常用的工具在后台偷偷霍霍硬件。 毕竟做开发者工具，尊重用户的硬件资源、不胡乱消耗用户的设备寿命，从来都不是什么加分项，而是最该做到的基础要求。