OpenAI Codex 遭爆正殺死你的 SSD：21 天寫入 37 TB，不到一年燒盡硬碟壽命

OpenAI Codex 的本地 SQLite feedback log 系統被發現存在嚴重的寫入失控問題：21 天累計寫入 37 TB，年化換算達 640 TB，遠超消費級 SSD 額定 TBW 壽命（300-600 TB）。
（前情提要：OpenAI 宣布「修補地球」計畫，為 cURL、Python、PyPI 等 19 個知名開源專案提供資安協助）
（背景補充：硬碟受驚竟會變慢！工程師對伺服器大吼，HDD 讀寫速度隨之驟降）

本文目錄

Toggle

一個 feedback log 如何在三週內逼近半 TB 等級
四條噪音管線同時開火
「不知情」才是真正的問題

二十一天，一顆消費級 SSD 的預期壽命從三到五年縮短成不到一年。這不是駭客攻擊，也不是挖礦程式，而是 OpenAI Codex 的本地 feedback log 系統在使用者不知情的情況下發生的。

這個問題由 GitHub 使用者 @1996fanrui 於本月中爆料。目前修復 PR 已合併，但開發團隊自己也承認，問題只解決了 85%。

一個 feedback log 如何在三週內逼近半 TB 等級

事件起點很平凡：@1996fanrui 在日常使用 Codex 時注意到本機磁碟空間異常消耗，追查後發現一個本地 SQLite 資料庫（簡單來說就是一個單一檔案構成的輕量型資料庫），在 21 天內累積寫入了 37 TB 的資料。

年化換算是 640 TB。

對照組：主流消費級 SSD 的 TBW（Total Bytes Written，硬碟製造商標注的額定寫入壽命）大約是 300 到 600 TB。這意味著如果任由 Codex 持續運作，不到一年就能把一顆全新硬碟寫到報廢。

資料庫目前磁碟佔用 1.2 GiB，保留約 506,149 筆 row。乍看之下不算誇張，但關鍵在歷史 row ID：高達 55 億。55 億 vs 50 萬，差距將近一萬倍。

這代表系統雖然有在清理舊紀錄，但寫入速度遠遠超過清理速度，整個過程如同一個從不停下的水龍頭，只是排水管比注水管粗了那麼一點點。

從 log 組成可以看出問題所在：TRACE 等級佔 70.7%，OpenTelemetry 遙測映象佔 25.3%，其他 3.9%。TRACE 是日誌等級中最低、最詳細的層級，簡單來說就是「記錄每一個動作，不管它有多瑣碎」。

在正式產品環境中，TRACE 通常不應該被持續寫入本地磁碟。

四條噪音管線同時開火

技術上，問題由四個主要來源構成。

第一是 WebSocket 事件 log。WebSocket 是瀏覽器與伺服器之間維持即時雙向通訊的協議，Codex 用它來接收串流補全結果。問題在於每一個底層 WebSocket 事件（包括心跳封包、連線確認、資料幀）都被記錄進 SQLite。對活躍使用者而言，這些事件每秒可能觸發數十次，log 量自然暴增。

第二是 inotify 通知。inotify 是 Linux 核心提供的檔案系統監控機制，可以即時偵測檔案的建立、修改、刪除。Codex 用它來監控工作目錄的變化，但同樣地，每一次監控事件都被忠實地寫進資料庫。在開發環境中，編譯器、套件管理工具、版本控制系統可能每秒產生數百個檔案系統事件。

第三是依賴套件內部 log。Codex 底層依賴的第三方套件在初始化或運作時，自身的 TRACE 等級日誌也被一併捕捉並寫入。這些 log 原本只應存在於套件的記憶體內部，而非被持久化到磁碟。

第四是 OpenTelemetry 遙測映象，佔總量的 25.3%。OpenTelemetry（簡稱 OTel）是業界標準的可觀測性框架，用來收集系統追蹤、指標與日誌。問題在於 Codex 把準備上傳到遠端遙測端點的資料，同時也完整複製一份到本地 SQLite，形成「資料映象」。這些資料的原始設計目的是送去 OpenAI 伺服器，不是長住使用者硬碟。

四條管線疊加，形成了 37 TB 的結果。

修復方案由兩個 PR 組成：PR #29432 停止記錄每個 WebSocket 事件，PR #29457 過濾高頻 target。官方表示這兩個修復合計消除約 85% 的問題寫入量。

但 15% 仍在：按 640 TB 年化基準換算，剩餘未解決的部分仍約 96 TB，依然是大多數消費級 SSD 的六分之一壽命。