在证据1里，这个日记库始终只有1.2GB，外面像什么都没产生；可它的自增行ID已经冲到55亿，真正留存的行不过50万出头，两者差了整整一万倍。
前段时光，一位开辟者在GitHub上提交了一个issue。这个如今标着“Closed”、编号#28224的GitHub issue，标题写着：
Codex的SQLite反馈日记一年能写640TB，敏捷耗尽固态硬盘寿命。
据这位申报者实测，他的主固态硬盘持续开机21天被写掉落37TB，照此推算一年约640TB，足够报废一块总写入量（TBW）为600TB的花费级硬盘。
为佐证，他贴出了两张表。
关键在于，硬盘损耗只算一共写过若干、不管此刻还剩若干：这55亿行全都落过盘，删掉落也退不回已经付出的写入。所以你查文件永远只看到那50万行，硬盘却早已扛下55亿行的写入量。
证据2裸露了这55亿行的分布：九成多是连开辟者本身都不会回头看的调试噪声，光把每条WebSocket数据包整包抄下来这一项，就占了一半。
祸首祸首，是一行Level::TRACE默认设备，它把你硬盘的写入寿命，当成了免费的草稿纸。
Hacker News上一条高赞评论，直接为这事定了性：
这是“劣质软件”（slopware）最臭名昭著的例子之一。
这位网友还无奈地甩出一句：
这真是个悲剧。这个世界，须要有人来和Anthropic竞争。
更难堪的是，这个问题不是没人报。
还有人想本身着手，却发明无从下手：这些对象的桌面端是闭源的。
评论区还有一句神评论：审查流程怎么没拦住这么明显的缺点？哦对了……@codex 审查一下这个。
而Codex这个“记录本身干了点什么”的日记功能，一年就能写满。
640TB
到底是怎么写出来的
640TB是什么概念。
从本年4月起就有零碎反馈，前后拖了两个多月，非要等用户本身测算、写申报、把它顶上Hacker News头条，才算被正经对待。即便如斯，这一轮也只砍掉落了约85%的日记写入。
主流花费级固态硬盘，标称写入寿命大年夜概150到600 TBW，够通俗用户用上十几二十年。
工作要从这位用户盘点硬盘说起。他的机械持续开机21天，主固态硬盘被写掉落了37TB。
更离谱的是写入方法。
Codex在本地保护着一个SQLite数据库logs_2.sqlite，专门记录反馈日记。这位用户抓了15秒——数据库被插入36211行，而保存的总行数，从头到尾都是681774，一个没多。
这套机制有个绰号，叫insert-and-prune：插入，然后急速删除。
更荒诞的是它记的器械：一堆文件体系的inotify事宜。
ld.so.cache被记了128764次，locale.alias37982次，passwd23843次。
同一个文件，被同一个法度榜样，反反复复记上十几万遍。
日记里的自增ID已经跨越55亿，而真正留存的行只有约50万。
申报者翻了Codex仓库，发明这类“日记无界增长”的Issue，至少有9个。
这不是bug，的确就像是一个AI编程对象在对着本身的硬盘反复念佛。
文件才1GB
写入倒是640TB
一边写一边删，留下的logs_2.sqlite能多大年夜？大年夜约1GB。
这就引出整件事最反常识的一点：固态硬盘的寿命看的是“写入量”，而非“文件大年夜小”。一个1GB的文件被反复擦写640次，对硬盘就等于写了640TB。
SQLite用的是WAL机制，每次修改先写进-wal文件，攒够再checkpoint回主库。Codex每15秒做三万多次插入加删除，每一次都要经由WAL、索引更新、checkpoint，同一块存储区，被擦了又擦。
打个比方：一本1GB的笔记本，你天天擦掉落重写1750遍，连写一年。笔记本照样那本，纸已经磨穿了。
这也是这个bug能埋伏这么久的原因：它不占空间，只烧寿命。
根因
一行被疏忽的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)把全局默认硬钉逝世在TRACE，RUST_LOG在这条路径上根本不生效。你认为本身关掉落了日记，它照写不误。
这种bug最坑人的处地点于，并非“你忘了设备”，而是“你设备了，它假装没听见”。
更刺目刺眼的是一个比例。
把保存的日记按类别拆开，TRACE占了70.7%，约732.5 MB。再加上codex_otel那两路镜像遥测日记（log_only和trace_safe），又占了25.3%。
七成写入是TRACE噪声，加上镜像遥测，96%满是没人会看的废话。
只有4%，才是真正有意义的内容。
这不是第一个
至少是第九个
#17320，流式响应时代WAL狂写，根因和此次一模一样，都是TRACE疏忽RUST_LOG。
#24275，桌面版logs_2.sqlite疯涨。
#22444，WAL无穷增长还占着空间不释放。
#26374，一天写0.75GB，没轮转。
#27911，一个4KB的goals_1.sqlite，被写成11MB/s。
#20563，过程闲着也狂写盘。
#27020，Windows上磁盘活泼100%。
最早的泉源能追到#12969，恰是这个PR把SQLite反馈日记的sink按TRACE级别接了进来。
一个4KB的数据库被写成每秒11MB，零丁拎出来都够写一篇。而它和640TB那个，是同一个产品、同一套遥测体系的症状。
这解释Codex的日记和遥测体系，从一开端就没有“资本预算”这个概念。
全部赛道都在卷token预算、卷高低文长度、卷模型才能。
但几乎没人问：一个常驻用户机械、7×24小时跑的Agent，它的磁盘、内存、CPU预算，谁来管？
那位开辟者的建议本来极简：给应用设条线，别跨越3GB。就这一条线，Codex拖了9个Issue、好几个月才肯画下来。
修了
两者差了一万倍。
但修得很OpenAI
6月14日报上GitHub，6月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续命。
两家旗舰，犯的是同一类缺点。
照这速度，一年约640TB。
社区里的评论，很快从一个bug，放大年夜到全部AI编程对象的质量问题。
有人吐槽这些智能体GPU常年跑满、内存动辄70GB，有人干脆给这代软件起了名字：劣质软件。
问题是一个时刻把“AGI”挂在嘴边的公司，为什么会栽在练习工程师都能看出来的问题上？
为什么这缺点能藏这么久，有条评论也说到了点子上。
放十年前，日记开到TRACE，法度榜样当场卡逝世，当天就被修掉落；如今CPU够快、内存够大年夜、磁盘够猛，这点缺点被硬件机能静静消化，法度榜样照跑、界面照常、用户无感，直到某天SSD提前报废。
查可用磁盘看不出异常，文件大年夜小一向很安静，只有去读硬盘本身的SMART健康计数，才能看到写入量在静静累积。
这两年，软件被AI生成的代码塞满，功能越堆越多、抽象层越叠越厚、资本消费一路狂飙，端赖硬件厂商每年用更快的芯片硬兜。
每插进一行，就有一行被删掉落。行数始终不变，磁盘却被往返擦写几万次。
于是有了一个荒诞轮回：软件越写越烂，硬件越造越猛。用户揣着“似乎没变慢”的错觉掏钱换新机，其实只是新机械勉强撑住了更烂的软件。
一个小bug当然无法压垮OpenAI。但Codex和Claude Code的竞争已经从模型才能，伸展到了开辟者工作流的进口。
在这条战线上，快速作出改变，响应开辟者需求从来不是加分项，只是入场券。
参考材料：
https://github.com/openai/codex/issues/28224
https://news.ycombinator.com/item?id=48626930
发表评论 取消回复