一年「吃掉」一块1TB的固态硬盘OpenAI的旗舰编程工具Codex正在以一年640TB的写入量烧穿你的固态硬盘。前段时间一位开发者在GitHub上提交了一个issue。这个如今标着「Closed」、编号#28224的GitHub issue标题写着Codex的SQLite反馈日志一年能写640TB迅速耗尽固态硬盘寿命。据这位报告者实测他的主固态硬盘连续开机21天被写掉37TB照此推算一年约640TB足够报废一块总写入量TBW为600TB的消费级硬盘。为佐证他贴出了两张表。在证据1里这个日志库始终只有1.2GB表面像什么都没发生可它的自增行ID已经冲到55亿真正留存的行不过50万出头两者差了整整一万倍。关键在于硬盘损耗只算一共写过多少、不管此刻还剩多少这55亿行全都落过盘删掉也退不回已经付出的写入。所以你查文件永远只看到那50万行硬盘却早已扛下55亿行的写入量。证据2暴露了这55亿行的分布九成多是连开发者自己都不会回头看的调试噪声光把每条WebSocket数据包整包抄下来这一项就占了一半。罪魁祸首是一行Level::TRACE默认配置它把你硬盘的写入寿命当成了免费的草稿纸。Hacker News上一条高赞评论直接为这事定了性这是「劣质软件」slopware最臭名昭著的例子之一。这位网友还无奈地甩出一句这真是个悲剧。这个世界需要有人来和Anthropic竞争。更尴尬的是这个问题不是没人报。从今年4月起就有零星反馈前后拖了两个多月非要等用户自己测算、写报告、把它顶上Hacker News头条才算被正经对待。即便如此这一轮也只砍掉了约85%的日志写入。还有人想自己动手却发现无从下手这些工具的桌面端是闭源的。评论区还有一句神评论审查流程怎么没拦住这么明显的错误哦对了……codex审查一下这个。640TB到底是怎么写出来的640TB是什么概念。主流消费级固态硬盘标称写入寿命大概150到600 TBW够普通用户用上十几二十年。而Codex这个「记录自己干了点什么」的日志功能一年就能写满。事情要从这位用户清点硬盘说起。他的机器连续开机21天主固态硬盘被写掉了37TB。照这速度一年约640TB。更离谱的是写入方式。Codex在本地维护着一个SQLite数据库logs_2.sqlite专门记录反馈日志。这位用户抓了15秒——数据库被插入36211行而保留的总行数从头到尾都是681774一个没多。每插进一行就有一行被删掉。行数始终不变磁盘却被来回擦写几万次。这套机制有个外号叫insert - and - prune插入然后立刻删除。更荒诞的是它记的东西一堆文件系统的inotify事件。ld.so.cache被记了128764次locale.alias37982次passwd23843次。同一个文件被同一个程序反反复复记上十几万遍。日志里的自增ID已经超过55亿而真正留存的行只有约50万。两者差了一万倍。这不是bug简直就像是一个AI编程工具在对着自己的硬盘反复念经。文件才1GB写入却是640TB一边写一边删留下的logs_2.sqlite能多大大约1GB。这就引出整件事最反常识的一点固态硬盘的寿命看的是「写入量」而非「文件大小」。一个1GB的文件被反复擦写640次对硬盘就等于写了640TB。SQLite用的是WAL机制每次改动先写进 - wal文件攒够再checkpoint回主库。Codex每15秒做三万多次插入加删除每一次都要经过WAL、索引更新、checkpoint同一块存储区被擦了又擦。打个比方一本1GB的笔记本你每天擦掉重写1750遍连写一年。笔记本还是那本纸已经磨穿了。这也是这个bug能潜伏这么久的原因它不占空间只烧寿命。查可用磁盘看不出异常文件大小一直很安静只有去读硬盘自己的SMART健康计数才能看到写入量在悄悄累积。根因一行被无视的RUST_LOG为什么会记这么多日志答案在Codex源码的一行配置里SQLite反馈日志的sink初始化时用的是Targets::new().with_default(Level::TRACE)。一句话日志默认开到TRACE级别最高、最啰嗦、什么都记的那一档。Codex的日志框架是Rust生态的tracing标准做法是读RUST_LOG环境变量。用户当然试过把RUST_LOG调成info、warn甚至直接关掉。没用。with_default(Level::TRACE)把全局默认硬钉死在TRACERUST_LOG在这条路径上根本不生效。你以为自己关掉了日志它照写不误。这种bug最坑人的地方在于并非「你忘了配置」而是「你配置了它假装没听见」。更刺眼的是一个比例。把保留的日志按类别拆开TRACE占了70.7%约732.5 MB。再加上codex_otel那两路镜像遥测日志log_only和trace_safe又占了25.3%。七成写入是TRACE噪声加上镜像遥测96%全是没人会看的废话。只有4%才是真正有意义的内容。这不是第一个至少是第九个报告者翻了Codex仓库发现这类「日志无界增长」的Issue至少有9个。#17320流式响应期间WAL狂写根因和这次一模一样都是TRACE无视RUST_LOG。#24275桌面版logs_2.sqlite疯涨。#22444WAL无限增长还占着空间不释放。#26374一天写0.75GB没轮转。#27911一个4KB的goals_1.sqlite被写成11MB/s。#20563进程闲着也狂写盘。#27020Windows上磁盘活跃100%。最早的源头能追到#12969正是这个PR把SQLite反馈日志的sink按TRACE级别接了进来。一个4KB的数据库被写成每秒11MB单独拎出来都够写一篇。而它和640TB那个是同一个产品、同一套遥测体系的症状。这说明Codex的日志和遥测系统从一开始就没有「资源预算」这个概念。整个赛道都在卷token预算、卷上下文长度、卷模型能力。但几乎没人问一个常驻用户机器、7×24小时跑的Agent它的磁盘、内存、CPU预算谁来管修了但修得很OpenAI6月14日报上GitHub6月23日报告者更新了一条三个PR已合并据他自己的Codex反馈能减少约85%日志于是宣布关闭。先说这个85%——不是100%而且还没全落地。三个修复里#29432、#29457已随0.142.0发布砍掉逐条WebSocket日志和噪声目标第三个#29599停掉另一类被桥接进来的冗余日志要等0.143.0才上线。即便三个全到位剩下约15%、一年仍要写约96TB不过是从「一年烧穿硬盘」降到「六年烧穿硬盘」。也有人替它辩护trace日志是按设计存下来调试的不算bug对OpenAI也确实方便追查边缘case。但问题恰恰在这儿拿付费用户的SSD寿命给厂商的debug做免费存储这事用户同意过吗编程战场烧穿的不只是SSD有意思的是被点名的并不只有Codex。评论区马上有人补刀Claude Code也往本地猛写调试日志有人只好把日志目录软链到内存盘tmpfs给SSD续命。两家旗舰犯的是同一类毛病。社区里的评论很快从一个bug放大到整个AI编程工具的质量问题。有人吐槽这些智能体GPU常年跑满、内存动辄70GB有人干脆给这代软件起了名字劣质软件。那位开发者的建议本来极简给应用设条线别超过3GB。就这一条线Codex拖了9个Issue、好几个月才肯画下来。问题是一个时刻把「AGI」挂在嘴边的公司为什么会栽在实习工程师都能看出来的问题上为什么这毛病能藏这么久有条评论也说到了点子上。放十年前日志开到TRACE程序当场卡死当天就被修掉如今CPU够快、内存够大、磁盘够猛这点毛病被硬件性能悄悄消化程序照跑、界面照常、用户无感直到某天SSD提前报废。这两年软件被AI生成的代码塞满功能越堆越多、抽象层越叠越厚、资源消耗一路狂飙全靠硬件厂商每年用更快的芯片硬兜。于是有了一个荒诞循环软件越写越烂硬件越造越猛。用户揣着「好像没变慢」的错觉掏钱换新机其实只是新机器勉强撑住了更烂的软件。一个小bug当然无法压垮OpenAI。但Codex和Claude Code的竞争已经从模型能力蔓延到了开发者工作流的入口。在这条战线上快速作出改变响应开发者需求从来不是加分项只是入场券。