@hqmank：Codex 透過 SQLite 頻繁寫入大量無用日誌，導致使用者 SSD 壽命加速耗損。 一張展示 Codex 軟體圖示與帶有 MP600 ELITE…

Codex 透過 SQLite 頻繁寫入大量無用日誌，導致使用者 SSD 壽命加速耗損。 一張展示 Codex 軟體圖示與帶有 MP600 ELITE 字樣的固態硬碟硬體，並輔以程式日誌背景的技術示意圖。 問題核心 開發者 hqmank 指出，Codex 軟體（包含 CLI、桌面版及 VSCode plugin）存在嚴重的過度寫入問題。即使在閒置狀態下，Codex 也會持續將大量 TRACE 等級的診斷日誌寫入 ~/.codex/logs_2.sqlite 資料庫。這些日誌包含大量無用的內部垃圾資訊，雖然檔案本身體積看似不大，但由於 SQLite 的寫入機制，底層會不斷進行磁碟刷新，導致 SSD 在短時間內承受巨大的寫入負載。 實際影響 根據 hqmank 的觀察，僅僅幾天的輕度使用，就產生了超過 78,000 筆 TRACE 紀錄，累積約 628 MB 的無用日誌。引用來源中的 GitHub 專案問題回報（Issue #28224）更進一步量化了此問題的嚴重性： 該日誌寫入量推算每年可達 640 TB，對於一般 1 TB 的消費級 SSD 而言，這意味著不到一年就會耗盡其保固內的寫入壽命（TBW）。 透過監測發現，該日誌系統存在嚴重的「寫入放大」現象，在 15 秒內即可插入超過 36,000 筆資料，隨後又立即刪除，導致磁碟不斷進行無效的寫入與索引更新。 解決方案 由於官方針對此問題的修復進度緩慢（儘管 GitHub 討論區顯示官方已於 2026 年 6 月 22 日合併了兩項 PR 以過濾部分日誌），hqmank 提供了一個立即可用的指令，透過在 SQLite 資料庫中建立觸發器（Trigger）來強制攔截並丟棄所有新的日誌寫入，且不會影響正常的對話功能： 開啟終端機並執行以下指令，將規則寫入日誌資料庫： `bash sqlite3 ~/.codex/logs2.sqlite "CREATE TRIGGER IF NOT EXISTS blocklog_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;" ` 執行後，該資料庫將不再接收任何新的寫入請求，從而保護 SSD 免受持續的損耗。 官方後續 根據 GitHub 上的更新，官方開發者 jif-oai 已合併了 Stop logging every Responses WebSocket event（PR #29432）與 Filter noisy targets from persistent logs（PR #29457），據稱可減少約 85% 的日誌寫入量，該 Issue 目前已關閉。建議使用者確認軟體版本更新，或視需求採取上述的觸發器手段進行防護。原文：https://easyvibecoding.app/curated/2147