Codex の SQLite フィードバックログが SSD を削る問題と応急処置

一部バージョンの Codex は ~/.codex/logs_2.sqlite に TRACE 既定で大量書き込みし、実測で数週間で数十 TB、年換算数百 TB 級の書き込みになりうる。ファイルサイズは小さく見えても insert→prune の増幅が本体。上流修正後もビルドによっては残るので、書き込み監視と応急トリガを知っておく。

どんなときに使う？

Codex 常駐後に SSD の寿命カウンタや iotop が異常
logs_2.sqlite / -wal の mtime が秒単位で動き、MAX(id) だけ増え続け retained rows はほぼ横ばい

症状の読み方

パス: ~/.codex/logs_2.sqlite（および -wal / -shm）
retained は数十万行でも、AUTOINCREMENT の MAX(id) が数十億に達している → 履歴のほぼ全部が prune 済みの書き込み
主因になりやすいもの: グローバル TRACE、WebSocket/SSE ペイロード、OTel ミラー行

応急処置（コミュニティで検証された例）

Codex を止めてから:

bash

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

以降の insert を無視して書き込みを止める。フィードバック送信前はトリガを外す必要ありうる
解除: DROP TRIGGER IF EXISTS block_log_inserts;
根本対処は Codex のバージョンアップ（0.142 / 0.143 系でフィルタ強化の PR がマージ）。それでも Desktop 経路で残る報告あり → 書き込みを実測して判断

注意点

RUST_LOG を下げてもこの SQLite シンクには効かない、という報告がある
VACUUM は一時的にさらに書く。まずトリガで止めてから容量回収を検討
エージェントがディスク逼迫時にファイル削除へ走る二次被害の報告もある（空き監視は重要）

出典

@about_hiroppy · 2026-06-22
GitHub Issue: github.com