一年「吃掉」一块1tb的固态硬盘？
OpenAI主推的编程助手Codex，正以年均640TB的写入量，悄然榨干你的SSD寿命。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
不久前，一名开发者在GitHub提交了一个issue。如今标记为「Closed」、编号#28224的该问题，标题直指核心：
Codex的SQLite反馈日志一年写入640TB，快速耗尽消费级固态硬盘的耐久性。
据其实际监测，主硬盘连续运行21天即被写入37TB，按此速率推算，全年约达640TB——足以超出一块标称TBW为600TB的主流SSD设计寿命。
为佐证观点，他附上了两张关键数据表。
证据1显示：日志数据库logs_2.sqlite当前仅占1.2GB，表面风平浪静；但其自增主键ID已飙升至55亿，而真实保留的有效记录却仅有50余万条，相差逾万倍。
重点在于：SSD寿命损耗只取决于累计写入总量，与当前文件大小或是否删除无关。这55亿次插入全部落盘执行过，哪怕后续被删，写入成本早已不可逆地发生。因此你每次打开文件看到的仍是那50万行，硬盘却早已承受了55亿次物理写入。
证据2揭示了这55亿条记录的构成：超九成属于开发者自身都极少回溯的调试冗余信息，其中单是完整镜像每一条WebSocket数据包这一项，就占据总量近一半。
根源在于一行默认配置：Level::TRACE。它把用户的硬盘写入寿命，当成了零成本的临时草稿纸。
Hacker News上一条高赞评论一针见血地定义了此事：
这是「劣质软件」（slopware）最具代表性的案例之一。
该网友还无奈补充道：
这真是一场悲剧。当今世界，亟需一家能真正挑战Anthropic的对手。
更令人尴尬的是，这个问题早非首次曝光。
自今年4月起便陆续有用户反馈，前后拖延两个多月，直到当事人完成实测建模、撰写详尽报告，并将其推上Hacker News热榜头条，才终于获得官方重视。即便如此，本轮修复也仅削减约85%的日志写入量。
还有人试图自行干预，却发现无从下手——这些工具的桌面客户端均为闭源。
评论区一句神评随即刷屏：代码审查流程为何没能拦截如此明显的缺陷？哦对……@codex，请先审查一下这个。
640TB，究竟是怎样被写出来的
640TB意味着什么？
当前主流消费级固态硬盘，标称TBW寿命普遍介于150–600TB之间，足够普通用户稳定使用十余年。
而Codex这项用于“记录自己做了什么”的日志功能，一年即可填满整块盘。
故事始于这位用户对硬盘使用情况的例行盘点。设备连续运行21天后，主SSD累计写入量已达37TB。
据此线性推算，全年约为640TB。
更令人咋舌的是其写入模式。
Codex本地维护一个名为logs_2.sqlite的SQLite数据库，专用于存储用户反馈日志。该用户仅抓取15秒操作——数据库内新增36211条记录，而总留存行数始终固定在681774，毫无变化。
即：每新增一行，就同步删除一行。总数恒定，磁盘却反复擦写数万次。
这套机制被戏称为insert-and-prune：插入即删。
尤为荒诞的是所记内容：大量重复的文件系统inotify事件。
ld.so.cache被记录128764次，locale.alias达37982次，passwd出现23843次。
同一文件，被同一进程，成千上万次重复登记。
日志表中自增ID已突破55亿，而实际保留在库中的有效条目仅约50万。
二者差距高达一万倍。
这并非偶然Bug，更像是一个AI编程工具对着自家硬盘持续诵经。
文件仅1GB，写入却达640TB
边写边删，最终留下的logs_2.sqlite有多大？约1GB。
这也引出了整件事最反直觉的一点：固态硬盘寿命取决于「总写入量」，而非「文件体积」。一个1GB的数据库若被反复覆盖640次，等效写入量就是640TB。
SQLite采用WAL（Write-Ahead Logging）机制，每次变更先写入-wal临时文件，积攒到阈值后再checkpoint合并进主库。Codex每15秒执行三万余次插入+删除操作，每一次均触发WAL写入、索引更新及checkpoint流程，导致同一物理存储区域被高频擦写。
打个比方：一本1GB的笔记本，你每天擦除重写1750遍，坚持一年。本子外观如初，纸张早已磨穿。
这也是该问题长期潜伏的原因：它不占空间，只烧寿命。
常规磁盘空间检查毫无异常，文件尺寸始终安静，唯有读取硬盘自身的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)将全局默认日志等级硬编码锁定在TRACE，使得RUST_LOG在此路径下完全失效。你以为关掉了日志，它仍在后台狂写不止。
这类Bug最致命之处在于，并非「你漏配了」，而是「你配了，它装作没看见」。
更刺眼的是占比结构。
将现存日志按类型拆解，TRACE层级日志占70.7%，约732.5MB；再加上codex_otel通道的两路遥测镜像日志（log_only和trace_safe），又占25.3%。
合计96%的写入量，全是无人查阅的冗余信息。
仅剩4%，才是具备实际价值的有效日志。
这不是首例，至少已是第九起
报告者梳理Codex仓库历史，发现类似「日志失控增长」的问题Issue，至少已有9个。
#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消耗，谁来约束？
修了，但修得相当OpenAI式
6月14日提交GitHub，6月23日，报告者更新状态：三个修复PR已合并，据其本地测试可降低约85%日志量，遂宣布关闭该issue。
先说这个85%——并非彻底清零，且尚未全面生效。
三项修复中，#29432与#29457已随v0.142.0版本发布，移除了逐条WebSocket日志及部分噪声目标；第三项#29599用于停用另一类桥接进来的冗余日志，需待v0.143.0上线。
即便三项全部落地，剩余约15%写入量仍将存在，折合全年仍约96TB——相当于从「一年报废SSD」降级为「六年报废SSD」。
也有人为其辩护：TRACE日志本就为调试而设，并非缺陷，对OpenAI排查边缘场景确实高效。
但问题恰恰在此：拿付费用户的SSD寿命，为厂商内部调试无偿买单，这件事，用户真的知情并授权了吗？
编程战场，烧穿的不只是SSD
有趣的是，被点名的远不止Codex。
评论区迅速有人跟进：Claude Code同样存在本地猛写调试日志的问题，部分用户被迫将日志目录软链接至内存盘（tmpfs），只为给SSD续命。
两大旗舰产品，犯的是同类错误。
社区讨论很快由单一Bug，升维至整个AI编程工具的质量信任危机。
有人吐槽这些智能体GPU常年满载、内存占用动辄70GB；也有人干脆为这代软件冠名：劣质软件。
那位开发者的原始建议极其朴素：为应用设定硬性上限，比如3GB。就这一条简单红线，Codex竟拖着9个Issue、耗费数月才勉强画下。
问题在于：一家时刻将「AGI」挂在嘴边的公司，为何会在连实习生都能一眼识别的工程问题上栽跟头？
为何此类缺陷能潜伏如此之久？一条评论切中要害：
十年前，日志开到TRACE，程序当场卡死，当天就会被修复；如今CPU更快、内存更大、SSD更强，这点性能损耗被硬件性能悄然吞没——程序照跑、界面照常、用户无感，直到某天SSD提前寿终正寝。
过去两年，AI生成代码大量涌入项目，功能越堆越臃肿、抽象层越叠越厚重、资源消耗一路飙升，全靠硬件厂商每年用更高性能芯片兜底。
于是形成一种荒诞循环：软件质量每况愈下，硬件性能节节攀升。用户抱着“好像没变慢”的错觉不断换新机，实则只是新设备勉强扛住了更烂的软件。
一个小Bug当然动摇不了OpenAI根基。但Codex与Claude Code的竞争，早已不止于模型能力，更蔓延至开发者工作流的第一入口。
在这条战线上，能否快速响应、切实解决开发者痛点，从来不是锦上添花，而是入场的基本门槛。
参考资料：
https://www.php.cn/link/1957a5ec9850b7d12ced5ba3d99c26e0
https://www.php.cn/link/4894bf7388f988505a90750b8b147a53
本文来自微信公众号“新智元”，作者：ASI启示录，36氪经授权发布。
