新智元報道

【新智元導讀】因為一個Bug，你的固態(tài)硬盤，正在被Codex悄悄寫穿。

一年「吃掉」一塊1TB的固態(tài)硬盤？

OpenAI的旗艦編程工具Codex，正在以一年640TB的寫入量，燒穿你的固態(tài)硬盤。

前段時間，一位開發(fā)者在GitHub上提交了一個issue。這個如今標著「Closed」、編號#28224的GitHub issue，標題寫著：

Codex的SQLite反饋日志一年能寫640TB，迅速耗盡固態(tài)硬盤壽命。

據(jù)這位報告者實測，他的主固態(tài)硬盤連續(xù)開機21天被寫掉37TB，照此推算一年約640TB，足夠報廢一塊總寫入量（TBW）為600TB的消費級硬盤。

為佐證，他貼出了兩張表。

在證據(jù)1里，這個日志庫始終只有1.2GB，表面像什么都沒發(fā)生；可它的自增行ID已經(jīng)沖到55億，真正留存的行不過50萬出頭，兩者差了整整一萬倍。

關(guān)鍵在于，硬盤損耗只算一共寫過多少、不管此刻還剩多少：這55億行全都落過盤，刪掉也退不回已經(jīng)付出的寫入。所以你查文件永遠只看到那50萬行，硬盤卻早已扛下55億行的寫入量。

證據(jù)2暴露了這55億行的分布：九成多是連開發(fā)者自己都不會回頭看的調(diào)試噪聲，光把每條WebSocket數(shù)據(jù)包整包抄下來這一項，就占了一半。

罪魁禍首，是一行Level::TRACE默認配置，它把你硬盤的寫入壽命，當成了免費的草稿紙。

Hacker News上一條高贊評論，直接為這事定了性：

這是「劣質(zhì)軟件」（slopware）最臭名昭著的例子之一。

這位網(wǎng)友還無奈地甩出一句：

這真是個悲劇。這個世界，需要有人來和Anthropic競爭。

更尷尬的是，這個問題不是沒人報。

從今年4月起就有零星反饋，前后拖了兩個多月，非要等用戶自己測算、寫報告、把它頂上Hacker News頭條，才算被正經(jīng)對待。即便如此，這一輪也只砍掉了約85%的日志寫入。

還有人想自己動手，卻發(fā)現(xiàn)無從下手：這些工具的桌面端是閉源的。

評論區(qū)還有一句神評論：審查流程怎么沒攔住這么明顯的錯誤？哦對了……@codex 審查一下這個。

640TB

到底是怎么寫出來的

640TB是什么概念。

主流消費級固態(tài)硬盤，標稱寫入壽命大概150到600 TBW，夠普通用戶用上十幾二十年。

而Codex這個「記錄自己干了點什么」的日志功能，一年就能寫滿。

事情要從這位用戶清點硬盤說起。他的機器連續(xù)開機21天，主固態(tài)硬盤被寫掉了37TB。

照這速度，一年約640TB。

更離譜的是寫入方式。

Codex在本地維護著一個SQLite數(shù)據(jù)庫logs_2.sqlite，專門記錄反饋日志。這位用戶抓了15秒——數(shù)據(jù)庫被插入36211行，而保留的總行數(shù)，從頭到尾都是681774，一個沒多。

每插進一行，就有一行被刪掉。行數(shù)始終不變，磁盤卻被來回擦寫幾萬次。

這套機制有個外號，叫insert-and-prune：插入，然后立刻刪除。

更荒誕的是它記的東西：一堆文件系統(tǒng)的inotify事件。

ld.so.cache被記了128764次，locale.alias37982次，passwd23843次。

同一個文件，被同一個程序，反反復復記上十幾萬遍。

日志里的自增ID已經(jīng)超過55億，而真正留存的行只有約50萬。

兩者差了一萬倍。

這不是bug，簡直就像是一個AI編程工具在對著自己的硬盤反復念經(jīng)。

文件才1GB

寫入?yún)s是640TB

一邊寫一邊刪，留下的logs_2.sqlite能多大？大約1GB。

這就引出整件事最反常識的一點：固態(tài)硬盤的壽命看的是「寫入量」，而非「文件大小」。一個1GB的文件被反復擦寫640次，對硬盤就等于寫了640TB。

SQLite用的是WAL機制，每次改動先寫進-wal文件，攢夠再checkpoint回主庫。Codex每15秒做三萬多次插入加刪除，每一次都要經(jīng)過WAL、索引更新、checkpoint，同一塊存儲區(qū)，被擦了又擦。

打個比方：一本1GB的筆記本，你每天擦掉重寫1750遍，連寫一年。筆記本還是那本，紙已經(jīng)磨穿了。

這也是這個bug能潛伏這么久的原因：它不占空間，只燒壽命。

查可用磁盤看不出異常，文件大小一直很安靜，只有去讀硬盤自己的SMART健康計數(shù)，才能看到寫入量在悄悄累積。

根因

一行被無視的RUST_LOG

為什么會記這么多日志？

答案在Codex源碼的一行配置里：SQLite反饋日志的sink，初始化時用的是Targets::new().with_default(Level::TRACE)。

一句話，日志默認開到TRACE級別，最高、最啰嗦、什么都記的那一檔。

Codex的日志框架是Rust生態(tài)的tracing，標準做法是讀RUST_LOG環(huán)境變量。用戶當然試過，把RUST_LOG調(diào)成info、warn，甚至直接關(guān)掉。

沒用。

with_default(Level::TRACE)把全局默認硬釘死在TRACE，RUST_LOG在這條路徑上根本不生效。你以為自己關(guān)掉了日志，它照寫不誤。

這種bug最坑人的地方在于，并非「你忘了配置」，而是「你配置了，它假裝沒聽見」。

更刺眼的是一個比例。

把保留的日志按類別拆開，TRACE占了70.7%，約732.5 MB。再加上codex_otel那兩路鏡像遙測日志（log_only和trace_safe），又占了25.3%。

七成寫入是TRACE噪聲，加上鏡像遙測，96%全是沒人會看的廢話。

只有4%，才是真正有意義的內(nèi)容。

這不是第一個

至少是第九個

報告者翻了Codex倉庫，發(fā)現(xiàn)這類「日志無界增長」的Issue，至少有9個。

#17320，流式響應(yīng)期間WAL狂寫，根因和這次一模一樣，都是TRACE無視RUST_LOG。

#24275，桌面版logs_2.sqlite瘋漲。

#22444，WAL無限增長還占著空間不釋放。

#26374，一天寫0.75GB，沒輪轉(zhuǎn)。

#27911，一個4KB的goals_1.sqlite，被寫成11MB/s。

#20563，進程閑著也狂寫盤。

#27020，Windows上磁盤活躍100%。

最早的源頭能追到#12969，正是這個PR把SQLite反饋日志的sink按TRACE級別接了進來。

一個4KB的數(shù)據(jù)庫被寫成每秒11MB，單獨拎出來都夠?qū)懸黄６?40TB那個，是同一個產(chǎn)品、同一套遙測體系的癥狀。

這說明Codex的日志和遙測系統(tǒng)，從一開始就沒有「資源預(yù)算」這個概念。

整個賽道都在卷token預(yù)算、卷上下文長度、卷模型能力。

但幾乎沒人問：一個常駐用戶機器、7×24小時跑的Agent，它的磁盤、內(nèi)存、CPU預(yù)算，誰來管？

修了

但修得很OpenAI

6月14日報上GitHub，6月23日，報告者更新了一條：三個PR已合并，據(jù)他自己的Codex反饋能減少約85%日志，于是宣布關(guān)閉。

先說這個85%——不是100%，而且還沒全落地。

三個修復里，#29432、#29457已隨0.142.0發(fā)布，砍掉逐條WebSocket日志和噪聲目標；第三個#29599停掉另一類被橋接進來的冗余日志，要等0.143.0才上線。

即便三個全到位，剩下約15%、一年仍要寫約96TB，不過是從「一年燒穿硬盤」降到「六年燒穿硬盤」。

也有人替它辯護：trace日志是按設(shè)計存下來調(diào)試的，不算bug，對OpenAI也確實方便追查邊緣case。

但問題恰恰在這兒：拿付費用戶的SSD壽命，給廠商的debug做免費存儲，這事，用戶同意過嗎？

編程戰(zhàn)場

燒穿的不只是SSD

有意思的是，被點名的并不只有Codex。

評論區(qū)馬上有人補刀：Claude Code也往本地猛寫調(diào)試日志，有人只好把日志目錄軟鏈到內(nèi)存盤（tmpfs），給SSD續(xù)命。

兩家旗艦，犯的是同一類毛病。

社區(qū)里的評論，很快從一個bug，放大到整個AI編程工具的質(zhì)量問題。

有人吐槽這些智能體GPU常年跑滿、內(nèi)存動輒70GB，有人干脆給這代軟件起了名字：劣質(zhì)軟件。

那位開發(fā)者的建議本來極簡：給應(yīng)用設(shè)條線，別超過3GB。就這一條線，Codex拖了9個Issue、好幾個月才肯畫下來。

問題是一個時刻把「AGI」掛在嘴邊的公司，為什么會栽在實習工程師都能看出來的問題上？

為什么這毛病能藏這么久，有條評論也說到了點子上。

放十年前，日志開到TRACE，程序當場卡死，當天就被修掉；如今CPU夠快、內(nèi)存夠大、磁盤夠猛，這點毛病被硬件性能悄悄消化，程序照跑、界面照常、用戶無感，直到某天SSD提前報廢。

這兩年，軟件被AI生成的代碼塞滿，功能越堆越多、抽象層越疊越厚、資源消耗一路狂飆，全靠硬件廠商每年用更快的芯片硬兜。

于是有了一個荒誕循環(huán)：軟件越寫越爛，硬件越造越猛。用戶揣著「好像沒變慢」的錯覺掏錢換新機，其實只是新機器勉強撐住了更爛的軟件。

一個小bug當然無法壓垮OpenAI。但Codex和Claude Code的競爭已經(jīng)從模型能力，蔓延到了開發(fā)者工作流的入口。

在這條戰(zhàn)線上，快速作出改變，響應(yīng)開發(fā)者需求從來不是加分項，只是入場券。

參考資料：

https://github.com/openai/codex/issues/28224

https://news.ycombinator.com/item?id=48626930

編輯：元宇