周末，AI开发者圈子被一个消息炸开了锅：Codex存在一个史诗级大Bug，正以惊人的速度“烧穿”用户的硬盘。据GitHub上的用户反馈和数据分析，Codex在流式传输和自动化任务时，会持续以约5MB/s的速度往磁盘写入日志，换算下来每年写入量高达640TB。而一块1TB的消费级SSD，官方标称的写入寿命（TBW）通常只有600TB左右。这意味着，你的硬盘可能撑不过一年就会因写入耗尽而报废。这个Bug的罪魁祸首是位于~/.codex/logs_2.sqlite的SQLite日志文件。文件中超过70%的内容是TRACE级别的日志，记录着inotify打开ld.so.cache、websocket收包、tokio内部状态等对用户毫无价值的内部噪音。更阴险的是，Codex一边写入一边删除：每15秒插入约36000行数据，文件大小看似稳定，但底层的WAL（预写日志）却在持续刷盘。用户反馈，机器开机跑21天，主盘总写入量增加了37TB，而主要写入源正是这个日志文件。有网友估算，256GB的QLC固态硬盘可能只能撑一个半月。评论区一片吐槽：有人表示电脑配置不低却越用越卡，切会话要等好几秒，甚至ccswitch切换都跟着卡顿，很可能就是这玩意儿在背后“磨盘”。目前，GitHub上已有大量issue详细记录了数据和影响，但官方自4月起至今未给出任何回应。社区提供了三种手动缓解方案。最暴力的方法是直接使用SQLite触发器阻止日志写入：执行sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"。温和一点的方法是将日志文件软链到内存盘（tmpfs），让它在内存里折腾，重启自动清空：mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak && ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite。如果家里有第二块机械硬盘，也可以直接挪过去，机械盘耐写。不过这些都只是临时workaround。这个事件暴露出AI工具在工程实现上的粗糙一面。相比于Claude的大文件是虚拟机镜像这类实际工作负载，Codex的日志纯粹是内部噪音。社区网友连补丁思路都写好了：给SQLite sink接上RUST_LOG的过滤规则。但OpenAI的沉默让不少人感到失望。趁你的SSD还没被磨穿，赶紧自己动手打个补丁吧。世界果然是个巨大的草台班子。