瘋狂向 SSD 寫入大量日誌 BUG 仍未除
【重大漏洞 ⚠️】OpenAI 旗下的 Codex 命令列介面（CLI）工具近日被揭發存在一項嚴重錯誤（Bug）。該工具在運作時會於背景瘋狂向本地資料庫寫入大量診斷日誌，一年內累積的寫入量恐高達 640 TB。這項嚴重漏洞若未能及時修正，將會在不到一年的時間內，徹底耗盡市面上主流消費級固態硬碟（SSD）的標稱壽命，導致硬碟面臨毀滅性損壞。
這項漏洞最早由 GitHub 用戶「1996fanrui」於本月 14 日揭露。該用戶注意到電腦出現異常的高磁碟活動率，經過深入調查後發現，Codex 工具正持續、高頻率地向一個位於本地的 SQLite 資料庫（路徑為 ~/.codex/logs_2.sqlite）寫入診斷日誌。數據顯示，在電腦連續開機運作的 21 天內，該硬碟就已被強行寫入約 37 TB 的數據；若換算成一整年的話，年寫入量將高達約 640 TB。
目前市面上主流的 1 TB 消費級固態硬碟，其平均標稱總寫入量（TBW，Total Bytes Written）大約為 600 TB。這意味著，一旦用戶長時間開啟 Codex CLI 工具而未加以防範，該漏洞所產生的寫入量將在一年內輕鬆超越硬碟的設計壽命，直接導致 SSD 過保。
技術分析指出，導致該漏洞的主因在於出廠時未妥善調整的日誌設定。Codex 預設將 SQLite 回饋接收器設定為最高級別且最為冗餘的「TRACE」層級。該設定會無差別記錄所有資訊，從原始的 WebSocket 負載到日常的檔案系統事件（例如開啟 passwd 或 ld.so.cache）皆全數寫入。即便用戶嘗試修改標準的環境變數（如 RUST_LOG），該工具亦完全忽視，導致用戶無法透過常規手段關閉日誌。
更棘手的是，該錯誤還引發了嚴重的「寫入放大（Write Amplification）」效應。資料庫並非單純隨檔案體積擴大而增長，而是每分鐘執行數萬次的「插入與刪除（Insert-and-Delete）」動態操作。這種高頻率的覆寫機制，使得硬碟實際承受的實體寫入負擔，遠比日誌檔案表面上的體積還要巨大。其中，有高達 71% 的數據被證實為對一般用戶毫無實質診斷價值的「TRACE 級雜訊」。
事實上，這項問題自今年 4 月起便已透過不同形式被陸續回報，GitHub 上也有多個相關的錯誤報告。儘管 OpenAI 最近的更新日誌中提及已針對 SQLite 的可靠性進行了部分修正，但顯然並未解決根本的「高頻率寫入」問題。截至目前為止，該項重大漏洞在 GitHub 上依然處於未解決（Open）狀態。
在官方尚未發布正式修復更新前，專家建議 Linux 與 macOS 的用戶採取應變措施，將硬碟中的 ~/.codex/logs_2.sqlite 檔案建立符號連結（Symlink）重新導向至記憶體（/tmp/）中。由於該日誌檔案並不包含任何對話內容，因此在電腦重新啟動後遺失並不會影響工具的正常運作。透過這種暫時性的最佳化設定，可有效防範硬碟因異常寫入而縮短壽命。
資料來源:
