OpenAI Codex 預設 TRACE 日誌 21 天向 SSD 寫入約 37 TB

一部執行 OpenAI Codex 的機器在連續運作 21 天期間，向主 SSD 寫入約 37 TB 資料。程序及檔案層級的檢查確認，持續寫入源自同一處：Codex 的本機 SQLite 回饋日誌 ~/.codex/logs_2.sqlite。按這個速度，硬碟每年約承受 640 TB 的寫入量，相當於對一隻 1 TB SSD 完整寫入約 640 次。許多消費級硬碟的額定耐寫量約為 600 TBW，因此單是 Codex，就可能在不到一年內耗盡硬碟的額定寫入耐久度。

資料庫看起來很小，保留約 50 萬列，容量約為 1.2 GiB。SQLite 的 AUTOINCREMENT 計數器才揭示了實際情況：其數值已超過 55 億，保留列數與曾插入的列數相差約 10,000 倍。在一次 15 秒的取樣中，約有 36,211 列寫入資料庫，但保留列數完全沒有變動。Codex 會批量插入資料、建立索引、寫入 WAL，然後在同一個交易內清除舊資料。檔案大小維持不變，磁碟卻持續承受寫入，因此最先顯現的問題是硬碟耗損，而非資料庫增大。

成因只有一行程式碼。app-server 和 TUI 都以全域 TRACE 預設值 Targets::new().with_default(Level::TRACE) 掛載 SQLite 持久化輸出端。每個目標都會以 TRACE 級別持久化，因此資料庫塞滿了沒有人選擇保留的日誌。寫入數 TB 資料的原因是預設日誌級別，而非偶然出現的程式碼路徑；每次安裝都採用這種設定。

哪些內容塞滿資料庫

高頻率資料列是相依套件產生的雜訊及原始協定流量：inotify 事件（ld.so.cache有 128,764 個 OPEN 事件，passwd有 23,843 個，nsswitch.conf和locale.alias則更多）、數以千計的 tokio-tungstenite poll_read和with_context項目、websocket frame 欄位，以及來自codex_otel.log_only和codex_otel.trace_safe的重複 OpenTelemetry 鏡像列。TRACE 單獨佔保留資料位元組的 70.7%；兩個 OTel 鏡像目標再佔 25.3%。移除這些類別，可在不關閉回饋日誌功能的情況下，減少約 96% 的保留日誌資料。原始 websocket 和 SSE 負載本文也會被持久化；報告者沒有將它們納入公開樣本，因為其中可能包含私人對話內容。

會造成甚麼問題

大型日誌資料庫造成的問題不止是磨損 SSD。啟動時，app-server 的 SQLite 連線池可能逾時（#27741）；而當 419 MB 的日誌資料庫與工作階段狀態同時存在時，在 WSL2 上曾導致冷啟動需時 1 至 5 分鐘（#28166）。一名留言者表示，Codex 在/goal模式下會為了騰出空間而刪除檔案和資料夾，因此磁碟空間用盡會導致資料遺失；Linux 電腦在磁碟空間用盡時重新啟動，亦可能無法登入。

修正措施及其不足之處

截至 2026 年 6 月下旬，已有三個 PR 合併；根據報告者自己的 Codex，這些修正令持久化日誌減少約 85%。#29432 停止記錄每個 Responses websocket 事件，#29457 則過濾嘈雜的目標，兩者均包含在 0.142.0 中；#29599 停止持久化橋接的日誌事件，包含在 0.143.0 中。OpenAI 表示，這一系列修正已包含在最新推出的桌面應用程式、CLI 及 IDE 擴充功能中。

並非所有修正都已推出。較後的一則留言指出，0.144.1 尚未包含 #31789 至 #31792；這些修正則見於 0.145.0-alpha.4，預計也會見於 0.145.0。另一個獨立根本原因由 #32496 追蹤：Codex 持續重寫models_cache.json和scope_v3.json，每年額外寫入約 1.3 TB，遠低於日誌寫入量，但仍是毫無必要的閒置 I/O。在 macOS 上以 GPT 5.6 Sol High 測試時，一名留言者量得，在套用上游修正後，未經處理的寫入量從每秒插入 33.1 個 ID 降至 7.36 個；使用本機篩選器後則降至 0.45 個。

緩解方法

在尚未包含修正的版本中，請先結束 Codex，再安裝一個會直接拒絕日誌插入的觸發器：

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

這會阻止所有插入操作，包括記錄回饋，但會立即停止寫入。幾位編寫出可正常運作的篩選器修補程式的人，無法將修補程式提交至上游：GitHub 在他們的帳戶上顯示「沒有正確權限可執行 CreatePullRequest」，因此無論如何，真正的修正都只能等待維護人員處理。