Codex CLIを常時起動していると、画面には何も出ないのにSSDが静かに消耗し続けます。2026年6月に公開されたGitHubの報告では、21日間の稼働だけで約37TBの書き込みが記録され、年換算すると約640TBに達する計算が示されています。
この記事では、OpenAI Codex CLIのSQLiteログ不具合について、原因・影響・確認方法・対処策を整理します。
この記事でわかること
- 年間640TB相当のSSD書き込みが起きる仕組み
- ディスク使用量に見えない「書き込み増幅」の正体
- 公式修正の状況（Codex 0.142.0以降）
- 今すぐできる確認方法と回避策
21日で37TB——異常な書き込み量
2026年6月14日、GitHubユーザー1996fanrui氏がIssue #28224を公開しました。Codex CLIがローカルのSQLiteデータベース（~/.codex/logs_2.sqlite）へ大量のログを書き続けている、という報告です。
同氏の環境では、マシンの稼働時間が約21日の時点で、メインSSDへの書き込み量が約37TBに達していました。これを年換算すると約640TB/年です。一般的な1TB SSDの保証書き込み量（TBW）は約600TB前後のため、理論上は1年以内に保証寿命を使い切るペースになります。
Issue #28224は公開から数日で300件以上のリアクションを集め、Hacker Newsでも注目を集めました。
ディスク容量は増えないのにSSDは削れる
この不具合が厄介なのは、見た目では異常が分かりにくい点です。ログデータベースは行を挿入しながら同時に削除するため、ファイルサイズは1.2GiB前後で推移します。15秒間の計測では約36,211行が挿入された一方、保持されている行数は約68万行でほぼ変わりませんでした。
SQLiteはWAL（Write-Ahead Logging）モードで動作しており、論理上のデータ量よりも物理的なフラッシュ書き込みが大きくなる「書き込み増幅」が起きます。duコマンドでディスク使用量を確認しても、SSDへの実際の書き込み負荷は見えません。
影響を確認するには、ドライブのSMART情報を読む必要があります。LinuxでNVMeドライブを使っている場合は、sudo smartctl -a /dev/nvme0の出力にある「Data Units Written」を確認します。Codexを1時間アイドル状態で動かした前後でこの値を比較し、ギガバイト単位で増えていれば不具合の影響を受けている可能性があります。
原因はTRACEレベルのログ設定
根本原因は、CodexのSQLiteフィードバックログシンクがグローバルTRACEレベルで動作していることです。コード上ではTargets::new().with_default(Level::TRACE)という設定が使われており、Rustのログフレームワークで最も詳細なレベルがデフォルトで有効になっています。
TRACEレベルでは、WebSocketやSSEの生ペイロード、inotifyによるファイル監視イベント（passwdやld.so.cacheのオープンなど）、tokio-tungsteniteの内部状態、OpenTelemetryのミラーイベントなど、診断価値の低い情報まで記録されます。保持ログのバイト数の約70.7%がTRACEレベル、さらにcodex_otel.log_onlyとcodex_otel.trace_safeで約25.3%を占めています。これらを除外すれば、保持ログの約96%を削減できる計算です。
さらに深刻なのは、標準的なログ制御手段であるRUST_LOG環境変数がこのSQLiteシンクに効かない点です。RUST_LOG=warnを設定してもTRACEレベルの書き込みは止まりません。この挙動は2026年4月10日に報告されたIssue #17320でも指摘されており、ストリーミング中に約5MiB/s（ピーク16MiB/s）の書き込みが観測されていました。
公式修正は0.142.0で一部リリース済み
OpenAIは2026年6月23日までに、関連する3つのプルリクエストをマージしています。
- #29432：Responses WebSocketイベントの逐次ログを停止（0.142.0でリリース）
- #29457：ノイズの多い永続ログターゲットと重複テレメトリのフィルタリング（0.142.0でリリース）
- #29599：ブリッジされた依存ライブラリのTRACEログのフィルタリング（0.143.0向け）
Codex 0.142.0のリリースノートには「Reduced persistent-log churn by removing per-event WebSocket payload logging and filtering duplicated telemetry records」と明記されています。報告者の環境では、これらの修正でログの約85%を削減できたと報告されています。
なお、Issue #28224は報告者が一度クローズしたものの、2026年6月24日時点では再オープン状態です。修正が完全に問題を解消したかどうかは、引き続きIssueの動向を確認する必要があります。
影響を受けやすい利用パターン
リスクはCodexの稼働時間に比例します。常時起動してバックグラウンドで動かし続ける開発者ほど、影響が大きくなります。
薄型ノートPCではSSDが基板上に実装されていることが多く、寿命切れの場合はドライブ単体の交換ではなく本体ごとの買い替えが必要になるケースがあります。Windows環境では、WSL2上でCodexを動かすとディスク使用率が100%に張り付く報告（Issue #27020）もあり、LinuxやmacOS向けの回避策がそのまま使えない点に注意が必要です。
別の報告では、ログファイルが約200MBを超えるとセッションが30〜105分でクラッシュする症状も指摘されています。長期間対策を取らずに使い続けている場合、SSD寿命だけでなく動作安定性にも影響が出る可能性があります。
今すぐできる確認と対処
まずはCodexのバージョンを確認します。
codex --version
0.142.0未満であれば、更新を最優先にしてください。更新後、ログファイルのサイズを確認します。
du -sh ~/.codex
ls -lh ~/.codex/logs_2.sqlite*
回避策1：SQLiteトリガーで書き込みをブロック
Codexを終了したうえで、以下のコマンドを実行します。ログの挿入をデータベースレベルで無視する方法で、Issue #28224で共有された回避策です。
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
診断ログも記録されなくなるため、恒久対策ではなく一時的な回避策として使います。
回避策2：ログファイルをRAMにリダイレクト
LinuxやmacOSでは、~/.codex/logs_2.sqliteを/tmp/へシンボリックリンクすることで、書き込み先をRAM上のtmpfsに切り替えられます。ログには会話データは含まれないため、再起動で消えても問題ありません。
回避策3：既存ログの削除とVACUUM
Codexを終了してから、古いログファイルを削除するかVACUUMを実行して容量を回収します。
rm ~/.codex/logs_2.sqlite*
または
sqlite3 ~/.codex/logs_2.sqlite "VACUUM;"
いずれの方法でも、Codex再起動後にログファイルは再作成されます。
AI開発ツールに求められる運用品質
この事例は、AIコーディングエージェントが長時間バックグラウンドで動作するようになったことで、従来のCLIツールにはなかったリスクが表面化したことを示しています。ツールは正常に応答し、ビルドも通る——その裏でSSDの書き込み寿命だけが静かに消費される、という構図です。
TRACEレベルのログを本番デフォルトにするのは、AI以前からある典型的な設計ミスです。ただし、エージェント型CLIはセッションを長時間維持し、WebSocketストリーミングでイベントを連続生成するため、同じ設定でも書き込み量は桁違いに膨らみます。
Codex CLIを使う開発者は、バージョン管理とSMART情報の定期確認を習慣にしておくのが現実的です。長時間稼働させるローカルエージェントには、ログの上限設定やストレージ使用量の可視化といった、サーバー運用と同じ発想のガードレールが必要になります。