AIじてん

English

CodexのSSD大量書き込みを診断ログ停止で抑える。実際に試した手順と注意点

AIコラム
ノートパソコンの診断ログが外付けSSDへ書き込まれる様子を描いたイラスト

Codexを使っているMacで、SSDへの書き込み量が異常に多くなる問題が話題になっています。原因として挙げられているのが、Codexの診断ログを保存する ~/.codex/logs_2.sqlite への大量のTRACEログです。

僕の環境でも調べてみたところ、30秒で約965行のログが追加されていました。そこで、診断ログのテーブルへの追加を止めるSQLiteトリガーを設定したところ、その後の測定では新しいログ行が増えない状態を確認できました。

この記事では、何が起きているのか、僕のMacで確認できた数字、実際に試した非公式の応急処置、元へ戻す方法をまとめます。情報は2026年7月29日時点のものです。

今回拝見した投稿はこちらです

きっかけになったのは、CodexアプリのSSD書き込み問題と、診断ログを停止する方法を紹介した投稿です。

Codexの診断ログがSSDへ書き込まれ続ける

Codexは、フィードバックや障害調査に使う診断ログを、次のSQLiteファイルへ保存しています。

~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm

問題は、通常の操作中にもTRACEレベルのログが高頻度で追加されることです。ログのデータベースだけでなく、WAL（Write-Ahead Log）にも書き込みが発生するため、SSDへの書き込み量やファイルサイズが増えていきます。

OpenAI CodexのIssue #31542では、HTTPリクエスト本文やストリーミング応答のペイロードがTRACEログへ書き込まれる仕組みが原因として説明されています。Issue #34291では、MCPツール一覧のような大きなJSON-RPCデータが1行約1.3MBになるケースも報告されています。どちらも2026年7月29日時点ではオープンのIssueです。

なお、ターミナルの標準出力向けログを絞る RUST_LOG を変更しても、SQLite側のログ保存は止まらない場合があります。標準出力のフィルターと、診断ログを保存するSQLiteのフィルターが別になっているためです。

僕のMacで実際に確認できたこと

Codex CLI 0.144.4を使っている環境で、診断ログDBを読み取り専用で調べました。

  • logs_2.sqliteは約371MB
  • 保持されているログは119,671行、推定データ量は約117.3MiB
  • TRACEレベルのログが推定データ量の約34%
  • codex_http_client::transportに1行約2.18〜2.19MiBの大きなTRACEレコードが4件
  • 操作中の30秒間で965行、推定約885KBが追加（約32行/秒）

主な発生源は codex_api::sse::responses のTRACEログでした。公式Issueで報告されている毎秒25〜41行という数字とも近く、過去のログが残っているだけではなく、現在進行形で書き込みが起きていると判断しました。

一方、MacのSSDについてはTRIMが有効でしたが、標準の情報だけでは総書き込み量や寿命残量までは確認できませんでした。今回の対処でSSDの寿命がどれだけ延びるかを測定したわけではなく、あくまで大量ログの追加を止められたかを確認しています。

試したのは、ログのINSERTを無視するSQLiteトリガー

今回試したのは、ログのINSERTをエラーにせず無視するSQLiteトリガーです。Codexの設定画面にある公式機能ではなく、データベースへ直接追加する非公式の応急処置です。

CREATE TRIGGER IF NOT EXISTS block_log_inserts
 BEFORE INSERT ON logs
 BEGIN
   SELECT RAISE(IGNORE);
 END;

INSERTが無視されるため、診断ログの新しい行は保存されません。書き込み処理そのものが完全に消えるわけではありませんが、TRACEログの大量追加と、それにともなうDB肥大化を抑える狙いです。

設定前に必ずCodex関連プロセスを終了する

SQLiteファイルを変更する前に、Codexアプリ、Codex CLI、VS CodeのCodex拡張など、対象DBを開く可能性のあるものをすべて終了します。

プロセス名を pgrep -fl 'Codex|codex' で探す方法もありますが、macOSではChatGPTアプリ内部の browser_crashpad_handler まで拾うことがありました。プロセス名ではなく、DBを実際に開いているかを lsof で確認する方が安全です。

lsof \
  ~/.codex/logs_2.sqlite \
  ~/.codex/logs_2.sqlite-wal \
  ~/.codex/logs_2.sqlite-shm

何も表示されなければ、次の作業へ進みます。心配な場合は、アプリを終了した状態でSQLiteファイルを別の場所へコピーしてから作業してください。

トリガーを追加して、再起動後に効果を確認する

まずDBの簡易整合性を確認します。

sqlite3 -readonly ~/.codex/logs_2.sqlite \
'PRAGMA quick_check;'

okと表示されたら、トリガーを追加します。

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

追加できたかは、次のコマンドで確認します。

sqlite3 -readonly ~/.codex/logs_2.sqlite \
"SELECT name FROM sqlite_master
 WHERE type='trigger'
 AND name='block_log_inserts';"

その後Codexを起動し、普段の操作を行った状態で、ログIDの最大値が変わらないかを確認します。

before_id=$(sqlite3 -readonly ~/.codex/logs_2.sqlite \
  'SELECT COALESCE(MAX(id),0) FROM logs;')

sleep 30

after_id=$(sqlite3 -readonly ~/.codex/logs_2.sqlite \
  'SELECT COALESCE(MAX(id),0) FROM logs;')

printf 'before=%s after=%s\n' "$before_id" "$after_id"

僕の環境では、トリガーが1件あることを確認したうえで、Codex再起動後に15秒間測定しました。測定前後の最大ログIDはどちらも 72683686 で、新しいログ行は増えていませんでした。

ただし、WALファイルの更新時刻は変化しました。SQLite関連のI/Oが完全にゼロになったわけではなく、大量のTRACE行追加が止まったと理解するのが正確です。

元に戻す方法と、適用をおすすめしない場面

元に戻すときもCodex関連プロセスを終了してから、次を実行します。

sqlite3 ~/.codex/logs_2.sqlite \
'DROP TRIGGER IF EXISTS block_log_inserts;'

診断ログが保存されなくなるため、/feedbackを使うときや、障害調査でログの提出を求められたときは、先にトリガーを削除して元の状態へ戻してください。OpenAI公式の設定ではないので、動作やサポートを保証するものでもありません。

また、Codexのアップデートや診断DBの再作成でトリガーが消える可能性があります。アップデート後は、トリガーの存在をもう一度確認してください。

state_5.sqliteや goals_1.sqlite、セッション関連のDBには適用しないでください。.codexディレクトリ全体を読み取り専用にする方法や、必要性を確認せず VACUUM を実行する方法も避けます。VACUUMはDB全体の再書き込みを行うため、別の大きな書き込みを発生させます。

まとめ

CodexのSSD大量書き込み問題は、診断ログ用SQLiteへTRACEレベルの大きなデータが高頻度で保存されることで、書き込み量やDBサイズが増える可能性があるというものです。僕の環境でも毎秒約32行の追加を確認し、非公式のSQLiteトリガーで新規ログ行の追加を止められました。

ただし、これは公式修正が出るまでの応急処置です。診断ログが必要なときは元へ戻し、適用する場合も対象ファイルを間違えないようにしてください。まずは lsof、quick_check、ログIDの前後比較という順番で、現在の環境に本当に大量書き込みが起きているかを確認してから判断するのがおすすめです。

関連記事

サイト内検索