現在很多人每天都會使用 Codex、Claude Code、Cursor 這類 AI 代理工具，有些人只是偶爾叫它寫個小程式，但有些人則是整天開著，讓它幫忙讀專案、跑指令、修 bug，甚至隨時遠端讓 AI 操作電腦。不過最近 Codex 被發現到一個蠻嚴重的問題，有用戶發現到，它在背景默默大量寫入 SSD，而且不是小量增加， 21 天內就有約 37TB 的寫入量，照這狀況，SSD 保固的寫入壽命很可能不到一年就耗盡。
使用者發現 Codex 背景持續寫入本機日誌，21 天累積約 37TB
根據外媒 NotebookCheck 報導，GitHub 使用者 1996fanrui 前陣子在 OpenAI Codex 的 GitHub issue 回報，他發現自己的電腦 SSD 寫入量異常偏高，進一步追查後，主要來源疑似是 Codex 在本機產生的日誌資料庫。
他從系統層面追查，到底是哪個程式、哪個檔案一直在寫入。最後發現 Codex 底下的本機日誌資料庫是主要持續寫入來源，相關檔案位在 ~/.codex/ 資料夾中，如：logs_2.sqlite 以及搭配 SQLite 使用的其他檔案：
這動作是 Codex 在本機記錄一些診斷資訊，方便之後除錯或回報問題。
一般來說很正常，因為很多 App 都會寫 log 日誌，但 Codex 的問題是寫的內容太多、太頻繁，包含大量一般使用者平常根本用不到的細節，如 TRACE、WebSocket、SSE 等。
根據 1996fanrui 描述，他的電腦已連續運作約 21 天，主 SSD 就累積約 37TB 寫入。如果把這個速度換算成一年，大約是 640TB。部分 1TB 消費級 SSD 的保固寫入壽命大約是 600TBW，意味著如果這情況長時間持續，不到一年內就可能耗盡 SSD 標示的 TBW 保固寫入耐久度。
當然，這不代表每一位 Codex 使用者都一定會遇到同樣程度的寫入量。37TB 是他觀察到的個案，640TB 則是依照這個個案速度換算出來的年化數字。不同使用習慣、不同版本、不同作業系統，實際情況都可能不同，有些人甚至沒有這種狀況。
不過由於這個數字實在是太恐怖，文章發表後立刻引起熱烈討論，很多重度用戶都開始擔心自己的 SSD 壽命。
好消息是，OpenAI 也關注到這個問題，該 issue 已關閉。作者也在更新中提到，當天有兩個相關 PR 合併，依他自己的 Codex 回饋，大約可減少約 85% 的日誌寫入量，因此他才選擇關閉。
另外在 Codex 0.142.0 的更新日誌中也寫到，也可以看到 OpenAI 把這件事列在 Chores 項目中，說明已透過取消記錄每次 WebSocket 事件的傳輸內容，以及過濾重複的診斷資料，來減少持續性的日誌寫入：
不過值得注意的是，Issue 關閉後還是有部分 Windows 與 macOS 使用者回報，最新版依舊存在持續寫入 SQLite 日誌的情況，因此 OpenAI 可能還需要進一步改善。
使用者可以怎麼叫 Codex 自檢？
如果你也擔心自己的 Codex 是否有類似問題，可以直接叫 Codex 幫你檢查，或在終端機執行以下指令：
ls -lh ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm 2>/dev/null
du -sh ~/.codex ~/.codex/sessions ~/.codex/logs_2.sqlite 2>/dev/null
sqlite3 ~/.codex/logs_2.sqlite "select count(*), sum(case when level='TRACE' then 1 else 0 end), max(id), datetime(min(ts),'unixepoch','localtime'), datetime(max(ts),'unixepoch','localtime') from logs;"
如果想觀察是否正在快速成長，可以做一個 30 秒前後比較：
before=$(sqlite3 ~/.codex/logs_2.sqlite "select count(*)||'|'||sum(case when level='TRACE' then 1 else 0 end)||'|'||max(id) from logs;"); echo $before; sleep 30; after=$(sqlite3 ~/.codex/logs_2.sqlite "select count(*)||'|'||sum(case when level='TRACE' then 1 else 0 end)||'|'||max(id) from logs;"); echo $after
判斷重點不是「有沒有 TRACE」，而是「檔案是否快速變大」、「WAL 是否一直膨脹」、「Codex 閒置時是否仍大量寫入」。如果 logs_2.sqlite 只有幾十 MB，WAL 只有幾 MB，短時間沒有成長，那通常不用緊張。反過來，如果 WAL 已經幾 GB、數十 GB，或幾分鐘內持續增加，就要處理。
真的遇到爆量該怎麼辦？
第一步是先關閉 Codex Desktop、Codex CLI、VS Code / Cursor / 其他可能啟動 Codex extension 的程式，並確認沒有 stale process 還握著 WAL 檔：
ps aux | egrep 'codex|app-server|SkyComputerUse|node_repl|cua_node' | grep -v egrep
lsof -nP +L1 | grep -i codex
如果看到已刪除的 logs_2.sqlite-wal 仍被 Codex process 開著，就要先正常退出那些 Codex session；必要時再終止 stale process。否則你就算刪掉檔案，磁碟空間也可能不會回來。
第二步是備份後再處理 SQLite log：
mkdir -p ~/.codex/log-backup
cp ~/.codex/logs_2.sqlite* ~/.codex/log-backup/ 2>/dev/null
如果只是檔案太大，且 Codex 已完全關閉，可以移走舊 log，讓 Codex 下次啟動重建：
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak-$(date +%Y%m%d-%H%M%S)
rm -f ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm
網路上也有人建議對 logs table 加 SQLite trigger，直接阻止新 log insert：
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
重要：這是 hack，不是正式修復。它可能讓 Codex 的本機診斷、錯誤回報或某些內部狀態追蹤失效。因此除非你已經確認 WAL 正在爆量，或磁碟空間正在被快速吃掉，否則不建議一開始就套這招。