【AI寫code隨時毀SSD】OpenAI Codex CLI日誌缺陷21天寫入37TB 每年640TB完爆消費級SSD上限 四月起問題已多次回報至今無正式修復　RUST_LOG環境變數設定被系統完全無視　導向/tmp係臨時解法

開發者社群近日揭露，OpenAI程式編寫工具Codex CLI（命令行介面版本）存在一個嚴重缺陷：程式在後台持續向本機SQLite資料庫寫入海量診斷日誌數據，且運行速度遠超正常水平。據研究人員實測報告，在21天的持續運行期間，受影響系統的固態硬碟（SSD）錄得約37TB的寫入量，按年化計算，相當於每年約640TB的驚人寫入數據。

全速追蹤模式 無法透過環境變數關閉

問題的根源在於Codex CLI的日誌記錄系統設計。程式將診斷日誌寫入本機路徑`~/.codex/logs_2.sqlite`的SQLite資料庫，且預設以最詳盡的TRACE（追蹤）級別全速記錄，涵蓋大量調試信息。

正常情況下，開發者可以透過設定`RUST_LOG=warn`環境變數，將日誌輸出限制在警告（Warning）級別以上，大幅減少日誌量。然而，研究人員發現，Codex CLI的SQLite日誌記錄模組完全無視`RUST_LOG`環境變數的設定，無論用戶如何配置，均維持TRACE級別的全速寫入，令用戶完全無法透過標準手段降低日誌量。

消費級SSD壽命 不足一年告終

37TB的21天寫入量，換算成年化數字為約640TB——而市場上主流的1TB容量消費級固態硬碟，其TBW（Terabytes Written，總寫入量壽命）評級通常在600TBW左右。這意味著，若Codex CLI持續運行，受影響的消費級SSD理論上在不足一年內便可能耗盡其全部寫入壽命，超出廠商保固範圍。

此問題首次被公開記錄於2026年6月14日，由開發者社群成員在代碼倉庫提交編號#28224的問題報告。事實上，相關問題自4月起已多次被用戶回報，但OpenAI至今未提供正式的完整修復版本。

三個拉取請求合併 已解決逾八成問題

值得留意的是，截至2026年6月23日，已有三個相關的拉取請求（Pull Request）被合併至程式碼庫，據評估可解決約85%的過量日誌問題。具體措施包括停止記錄WebSocket事件、過濾高噪音的日誌目標，以及停止持久化已橋接的日誌事件等。然而，針對`RUST_LOG`環境變數被系統完全無視的根本問題，官方尚未就此提供完整說明或最終修復。

用戶臨時應對方案

對於Linux及macOS系統用戶，目前有一個可操作的臨時緩解方案：將日誌資料庫檔案`~/.codex/logs_2.sqlite`建立符號連結（Symlink），導向至系統的暫存目錄`/tmp/`。由於`/tmp`目錄的數據存放於系統記憶體（RAM）中，寫入操作不會對SSD造成實際磨損，且由於該日誌檔案不包含任何對話記錄或用戶數據，在系統重啟後消失亦不會導致重要數據損失。

此次Codex CLI缺陷事件揭示了AI開發工具在快速迭代過程中，質量保證機制仍存在明顯盲點。消費者在採用任何AI編程輔助工具前，應留意其對本機硬件資源的實際消耗，而非僅關注功能層面的表現。相關問題是否已透過最新版本得到完整解決，仍有待官方正式確認。

免責聲明：本專頁刊載的所有投資分析技巧，只可作參考用途。市場瞬息萬變，讀者在作出投資決定前理應審慎，並主動掌握市場最新狀況。若不幸招致任何損失，概與本刊及相關作者無關。而本集團旗下網站或社交平台的網誌內容及觀點，僅屬筆者個人意見，與新傳媒立場無關。本集團旗下網站對因上述人士張貼之資訊內容所帶來之損失或損害概不負責。