[AI 風險提醒] Codex SSD異常寫入問題

 [AI 風險提醒] Codex SSD異常寫入問題

摘要 : Codex本地日誌疑似以Trace級別持續寫入SQLite，可能造成SSD壽命、效能與隱私風險。

內容:

近期有使用者回報，OpenAI Codex CLI 與桌面版可能出現 SSD 寫入放大問題，主因疑似來自本地診斷日誌持續以高頻率寫入 SQLite。若你最近有使用 Codex，建議先檢查本機的日誌檔案是否異常成長，避免 SSD 健康度持續受影響。

自查方式很簡單。Windows 使用者可到使用者個人目錄下的 Codex 資料夾查看 `Logs.r.sqlite`；macOS 與 Linux 使用者則到對應的 Codex 目錄檢查相同檔案。若旁邊同時看到 `WAL` 與 `SHM` 檔案屬正常情況，因為 Codex 採用 SQLite。但若發現 WAL 檔在短時間內快速變大，或只要開啟 Codex 磁碟寫入就長時間偏高，就要特別注意。

根據社群回報，這個問題已被多位使用者重現，有案例指出 21 天內寫入 37TB，也有人在 10 分鐘內寫入 7GB。對一般消費級 SSD 而言，這樣的寫入量相當可觀，可能對壽命造成實質影響。

問題核心不在於「寫日誌」本身，而是預設日誌級別疑似設為 Trace。Trace 屬於非常細緻的開發級日誌，適合除錯與深度排查，但不適合長期預設寫入本地資料庫。更麻煩的是，這部分 SQLite 日誌行為似乎不完全受 Rust Log 設定控制，因此即使用戶已將日誌等級調成 `warn`，本地 SQLite 仍可能持續寫入大量 Trace 級內容。

從已公開的資訊來看，寫入量較大的來源之一是 Responses WebSocket 的原始回應紀錄，另外還包含 OpenTelemetry 相關事件與部分底層依賴日誌。這些內容對一般使用者排查幫助有限，但若全部持久化進 SQLite，就容易形成高頻率、大體積的磁碟寫入。

除了 SSD 壽命外，這件事也牽涉效能、穩定性與隱私。首先，日誌資料庫持續膨脹後，Codex 桌面端可能會越來越慢，特別是在 WSL2 或本身磁碟壓力較高的環境中，可能出現磁碟活躍時間接近 100%。其次，若 `Logs.r.sqlite` 與 WAL 檔過大，可能導致啟動時 SQLite 連線超時，甚至讓 Codex 無法正常開啟。再者，若日誌中保存了 WebSocket 原始內容、對話資訊或任務上下文，也可能帶來本地隱私與資料治理風險。

截至 2026 年 6 月 23 日，GitHub 上已有兩個相關修正 PR 合併進主分支。其一是停止記錄每個成功的 Responses WebSocket 事件；其二是從持久化日誌中過濾高噪音目標，例如部分橋接日誌與 OpenTelemetry 映射事件。這些調整的方向都很明確，就是減少無效日誌寫入本地 SQLite。不過，PR 合併進主分支不代表你目前安裝的版本已經包含修復，因此仍需自行更新並觀察。

如果你是一般使用者，建議先做三件事。第一，立即更新 Codex 到最新版本。第二，完全退出 Codex 後，檢查 Codex 目錄中的 `Logs.r.sqlite`、`Logs.r.sqlite-wal` 與 `Logs.r.sqlite-shm` 是否異常肥大。第三，確認更新後磁碟寫入是否恢復正常。處理時建議只針對日誌檔案，不要直接刪除整個 Codex 目錄，以免誤刪設定或其他重要資料。

如果你是技術人員，或必須暫時使用尚未修復的舊版 Codex，可以考慮一些臨時措施。例如定期執行 SQLite 的 WAL checkpoint，以減少 WAL 檔長期膨脹；但這只能緩解檔案變大，無法真正解決持續寫入問題。更進一步的方式是對 Logs 表建立攔截插入的觸發器，直接阻止日誌寫入，但代價是未來若遇到問題，開發者可用的診斷資訊也會同步減少。另有人會把 Codex 放到 RAM Disk，以避免 SSD 持續被寫入，但這較偏向權宜之計，未必適合所有人。

對團隊與 IT 管理者而言，這次事件也是一個提醒。AI 程式工具不只要評估功能與產出品質，也應納入終端監控範圍，包括磁碟寫入量、日誌目錄大小與程序異常狀態。若工具涉及對話、程式碼片段或業務上下文，更應明確規範儲存位置、保留時間與清理機制，並建立簡單 SOP，讓團隊遇到卡頓或寫入異常時能快速排查與處理。

整體來看，這次 Codex SSD 寫入放大問題，本質上是預設日誌級別與持久化策略設計不當所引發。若你目前仍在使用 Codex，建議立即更新版本、檢查日誌檔案大小，並確認系統磁碟寫入是否存在異常增長。