テック技報最新号へ →
AIコーディング

Codex のローカルログで SSD が削れていないか確認する

Codex は ~/.codex/logs_2.sqlite にフィードバックログを書き続け、TRACE ログやテレメトリの複製で、ある報告では21日で約37TB（年640TB相当）の書き込みになった。0.142〜0.143 の修正で約85%減ったので、まず更新する。

@about_hiroppy · 投稿 2026-06-22
#ai-coding#codex#ログ#ssd#トラブルシュート

確認と対処

  1. Codex のバージョンを確認し、0.143.0 以降に上げる（修正 PR は 0.142.0 と 0.143.0 で順次リリース）
  2. ログ DB のサイズを見る: ls -lh ~/.codex/logs_2.sqlite*（本体・-wal・-shm）
  3. OS の書き込み量（macOS ならアクティビティモニタのディスク、Linux なら iotop など）で Codex が上位にいないか確認する
  4. 古い版のまま使う必要がある場合の回避策として、issue では Codex を終了してから次を実行し、ログの挿入を無視させる方法が共有されている
bash
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

注意点

  • 回避策はフィードバック用ログを捨てるので、不具合報告に必要なログも残らなくなる。更新できるなら更新を優先する
  • 主な原因は WebSocket/SSE の生ペイロードを含む TRACE ログ（保持量の約7割）と OpenTelemetry 系ログの複製だった
  • 常時起動のエージェントは、ログ・キャッシュの書き込み量も定期的に見ておく

出典

X の元の投稿を開く