Codex CLI を使い続けると SSD の寿命が縮む? SQLite ログ肥大バグの実態と企業への教訓

Codex CLI を動かしているだけで SSD が削られている。稼働 21 日で 37TB——それが GitHub Issue #28224 に報告された実測値です。

AI コーディングエージェントを評価する時、出力の質やコスト、セキュリティは議論に上がります。しかし「ローカルマシンのハードウェアに何が起きているか」は後回しになりがちです。この記事では、Codex CLI の SQLite ログ肥大バグの実態と、現時点での対処を整理します。

何が起きたか

Codex CLI は、フィードバック収集のためのログを ~/.codex/logs_2.sqlite(および -wal / -shm ファイル)へ継続的に書き込みます。

GitHub Issue #28224 の報告者が実測したところ、稼働 約21日でメイン SSD への書き込みが約 37TB に達していました。これを年換算すると 約 640TB/年 に相当します。

ログの内容は多岐にわたります。依存ライブラリの内部イベント、生の WebSocket/SSE ペイロード、OpenTelemetry のミラーイベントが、フィードバック用の SQLite データベースに際限なく蓄積されていました。問題をさらに複雑にするのは、RUST_LOG=warn を設定しても TRACE レベルのエントリが書き込まれ続けた点です。このログ sink は RUST_LOG フィルタの外で動作しているため、環境変数でログレベルを制限しようとしても効果がありませんでした。

書き込みの様子を 15 秒間サンプリングした観察では、約 36,211 行が INSERT される一方、保持行数は横ばいでした。削除と挿入を繰り返す「insert→prune」パターンによって、実際のデータ増加量を大きく上回る書き込みが発生する「書き込み増幅」が起きていました。

なぜ起きるのか

根本原因は、SQLite へのフィードバックログ書き込み先(sink)が デフォルトで TRACE レベル(最も詳細) に設定されていたことです。

通常、RUST_LOG 環境変数を設定すれば Rust 製ツールのログ出力レベルを制御できます。しかしこの sink は RUST_LOG フィルタリングの外側で動作するよう実装されており、ユーザーが RUST_LOG=warn を指定しても TRACE の書き込みは止まりませんでした。

GitHub Issue #17320 はこの挙動を「TRACE logs ignoring RUST_LOG」と明確に記述しており、ストリーミング応答中に SQLite ログへ 毎秒 約 5MiB が書き込まれるとの指摘も含まれています。

どれくらい深刻か

SSD の耐久性は「TBW(Total Bytes Written)」という指標で表されます。Issue #28224 内でも引用されているとおり、コンシューマ向け 1TB SSD の保証書き込み量は製品によって異なり、約 600TBW 前後のものがあります。より高 TBW の製品では影響が小さくなる場合もあります。

Codex CLI が引き起こし得る約 640TB/年 という書き込み量は、1 年未満で保証耐久量を使い切り得る 規模です。1TB SSD なら年間 約 640 回のフルドライブ書き込みに相当します。ただし、これは特定の環境・使用量での実測を年換算した推計値です。Codex の使用頻度や環境によって実際の影響は変わります。

公式の対応と現状

Issue #28224 は 2026-06-23 にクローズされました。対応は 3 つの PR に分かれています。

• PR #29432「Stop logging every Responses WebSocket event」 — マージ済み、v0.142.0 でリリース済み
• PR #29457「Filter noisy targets from persistent logs」 — v0.142.0 でリリース済み
• PR #29599「Stop persisting bridged log events」 — v0.143.0 で対応予定

Issue #28224 の記述によれば、これらによってログ書き込みの 約 85% が削減される と見込まれています。

一方、RUST_LOG フィルタが無視されるという根本の挙動を報告した Issue #17320 は、現時点でも Open(未解決) のままです。つまり現状は「公式の緩和策がリリース済みだが、RUST_LOG を無視する根本の挙動は追跡中」という段階です。

企業が取るべき対策

まず最新版への更新を

最優先は Codex CLI を v0.142.0 以降に更新すること です。緩和策はすでにリリースされており、更新だけで書き込みの約 85% を削減できます。

書き込み量を把握する

影響を確認する手順としては、OS 側の SSD 総書き込み量(smartctl 等で参照できる「host writes」)と、~/.codex/logs_2.sqlite のサイズ・更新頻度を定期的に観察することが有効です。数値を確認しないまま「問題ない」と判断するのは根拠がありません。

非公式の回避策について

Issue #28224 のコメントでは、以下のような回避策が提案されています。

• logs テーブルへの INSERT を無視する SQLite トリガを作成する
• ログ DB ファイルを tmpfs(RAM)上へ逃がしてシンボリックリンクで差し替える

これらは 公式サポート外の応急策 です。Codex のバージョン更新でテーブルが再生成されると無効化される可能性があり、更新後の再確認が必要です。最新版への更新でほぼカバーできる状況でも、環境によってはこれらを追加の防御手段として組み合わせることができます。

まとめ——内製で AI ツールを使う組織への教訓

AI コーディングツールは機能の進化が速い分、バグや予期しない挙動が頻繁に報告されます。今回の問題は、ツールを評価する視点が「出力品質」に偏ると、ハードウェアへの副作用を見落とすことを示しています。

やることは単純です。まず smartctl -A <device> で現在の host writes を確認する。次に Codex を v0.142.0 以降に更新する。それだけで今日の問題のほぼ 85% は解消されます。残りの根本的なフィルタ問題(Issue #17320)は引き続き Open のため、GitHub を watch して修正が入ったら再度更新する——これが現時点での正解です。

ツールのリリースノートとバグトラッカーを追跡し、既知の問題が修正されたら速やかに更新する。それと並行して、SSD 書き込み量のような目に見えにくいリソース消費を定期的に観測する仕組みをチームの運用に組み込む。どちらも高度な監視基盤は不要で、smartctl で数値を見る習慣から始められます。

---

出典

• GitHub Issue #28224 — "Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance": https://github.com/openai/codex/issues/28224
• GitHub Issue #17320 — "Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG": https://github.com/openai/codex/issues/17320