OpenAIが提供するコーディングエージェント「Codex CLI」のバックグラウンド処理において、ユーザーのローカルストレージに対して異常な規模のデータ書き込みが継続的に行われている事実が明らかになった。事の発端は、Apache Flinkのプロジェクト管理委員会メンバーであるRui FanがGitHubに報告したIssue #28224である。この報告によれば、Codex CLIを稼働させたマシンで21日間の連続起動を行った結果、メインのSSDに対して約37TBという膨大なデータの書き込みが記録されていた。
このペースを1年間に換算すると、約640TBの書き込み量に達する。一般に流通している1TBクラスのコンシューマー向けSSDの耐久性（TBW：Total Bytes Written）は、Samsung 9100 PROなどを例にとっても600TB程度に設定されている。つまり、このCodex CLIの不具合は、一般的なSSDの製品寿命として想定された書き込み可能領域を、わずか1年未満で完全に食いつぶすことを意味する。
SSDはフラッシュメモリの特性上、データを書き込むたびにセルが物理的に劣化し、TBWの制限を超過すると性能の低下や突然のデータ消失を招く。この過剰な書き込みは、ユーザーのストレージの経済的価値を著しく損なう。Rui Fanの例では、SSDのTBW単価（ドライブ価格を保証TBWで割った値）に基づく試算で、37TBの無駄な書き込みが約12ドル分のストレージ寿命を消費したと見積もられている。開発コミュニティ全体で見れば、この不具合が放置された期間中に数百万ドル規模のハードウェア寿命が不必要に削られたという推計も提示されている。
過剰書き込みを引き起こすSQLiteとWALの書き込み増幅機構
この不具合が深刻なのは、標準的な監視ツールではディスクスペースの圧迫として検知されにくい点にある。Codex CLIはローカルに「logs_2.sqlite」というSQLiteデータベースを作成し、そこへログを保存する。しかし、このデータベースは挿入された古い行を高速に削除（Prune）し続けるため、論理的なファイルサイズ自体は数百メガバイト程度からほとんど増加しない。Issueの検証でも、15秒間に3万6,211行が挿入されたにもかかわらず、データベース全体の行数は約68万行でほぼ横ばいを維持していた。「du」コマンドなどでファイルサイズを監視していても、異常は表面化しない。
ファイルサイズが増加しない背後で、SQLiteのWrite-Ahead Logging（WAL）モードによる書き込み増幅（Write Amplification）がストレージを削り続けている。WALモードでは、すべてのデータ変更がまず独立したジャーナルファイル（-wal）に追記され、その後のチェックポイント処理でメインデータベースへマージされる。Codex CLIのログ処理では1分間に数万回もの挿入と削除のサイクルが発生し、これに伴う頻繁なチェックポイント処理がフラッシュメモリへの物理的な書き込みを激しく繰り返す。
論理的なデータ量は一定に保たれていても、物理的なフラッシュセルへの書き込みは数倍に膨れ上がる。この書き込み増幅こそが、ディスク容量を圧迫せずにSSDの寿命だけを静かに奪うメカニズムである。ユーザーがこの物理的書き込み量を正確に把握するには、論理ファイルサイズではなく、Linux環境であれば「smartctl」コマンド等を用いてNVMeドライブなら「Data Units Written」、SATAドライブなら「Total_LBAs_Written」といったSSD自体のSMARTデータを直接読み取る以外に方法はない。
制御不能なTRACEログと開発側の実装不備
異常な量のログが生成される原因は、Codex CLI内部のロガー設定における初歩的かつ致命的な欠陥に起因する。該当のSQLiteフィードバックログは、初期設定で「Level::TRACE」に固定されている。TRACEレベルはログ出力のなかで最も冗長な設定であり、通常は深いデバッグ作業時にのみ有効化されるべき機能である。Codexの出力には、生のWebSocketやSSEのペイロード、「passwd」や「ld.so.cache」といったOSレベルのファイルアクセスイベント、さらには「tokio-tungstenite」や「hyper_util」といった内部の依存ライブラリから発生する細かな状態変化まで、すべてが無差別に記録されている。
分析によると、出力されるログの70.7%はこのTRACEレベルの記述であり、これにOpenTelemetryのミラーイベント（25.3%）を加えると、全書き込み量の約96%を占める。これらのデータの大半は、一般的なユーザー環境において診断用途としての実質的な価値を持たない。製品版のソフトウェアにおいてこのような過剰なログを常時出力する設定は、本番環境への配備基準を大きく逸脱している。
問題を悪化させているのは、このロガーがRustアプリケーションにおける標準的なログレベル制御変数である「RUST_LOG」を完全にバイパスしている事実である。ユーザー側で環境変数を「RUST_LOG=warn」などに設定し、出力を警告以上に絞ろうと試みても、CodexのSQLiteロガーはそれを無視してTRACEレベルでの記録を続行する。ユーザーの手元に制御を委ねず、最高レベルの冗長性でデータを吐き出し続ける仕様が、被害を回避不可能にしていた。
これらの不自然な挙動は、突発的に生じたものではない。4月10日の時点ですでにIssue #17320として、RUST_LOGを無視するTRACEログがストリーミング中に過剰なWAL書き込みを発生させる問題が報告されていた。その後も複数の報告が上がっていたにもかかわらず、数ヶ月にわたって根本的な修正が提供されなかった事実は、開発プロセスの盲点を示している。
ユーザー側の暫定対応と修正状況
OpenAIからの公式な修正が提供されない中、LinuxおよびmacOSのユーザーコミュニティは自衛のための暫定的な回避策を編み出した。それは、問題のSQLiteファイル（~/.codex/logs_2.sqlite）をRAMディスクである「/tmp」へシンボリックリンクするという手法である。「/tmp」は物理的なフラッシュストレージではなく揮発性のメモリ上に展開されるため、どれだけ書き込みが発生してもSSDの寿命を消耗しない。このログファイルには復元すべき会話履歴やユーザーデータは含まれておらず、再起動時に消去されても実用上の不都合は生じない。
別の回避策として、SQLiteのトリガーを作成してログテーブルへのINSERT処理をブロックし、書き込み自体を物理的に無効化する手法や、既存のファイルに対して「VACUUM」コマンドを実行して数十GBに膨れ上がった不要領域を解放する手法も共有されている。しかし、Windows環境（WSL2を含む）のユーザーにとっては、これらと同等の容易な回避策は確立されていない。タスクマネージャー上でディスク使用率が100%に張り付く現象が報告される中、根本的な解決を待つしかない状況が続いた。
事態が動いたのは6月22日である。OpenAIの開発チームは関連するIssueに対応し、不要なログの出力を大幅に削減する修正パッチを反映したアップデートを適用した。ユーザーはCodex CLIを最新版へアップデートした上で、肥大化した「logs_2.sqlite」ファイルを手動で削除することが推奨されている。起動時に新しくクリーンなデータベースが作成されることで、ようやくSSDへの過剰な負荷は正常な範囲に収まる。
常駐型AIエージェントがもたらす新たなハードウェアリスク
一連の騒動は、AI開発ツールの進化がもたらす新しい種類のリスクを顕在化させた。従来のソフトウェアとは異なり、Codex CLIのようなAIエージェントはバックグラウンドで常に稼働し続ける。さらに4月のアップデートではmacOS環境でのフルデスクトップ操作権限が付与され、ユーザーの画面を定期的にキャプチャする機能が導入されるなど、エージェントがローカルシステムにアクセスする権限は急速に拡大している。
高い権限を持ったプロセスが常に背後で動く環境において、ログ出力のバグという一見些細な実装のミスは、ユーザーが気づかないうちに物理的ハードウェアを不可逆的に損傷させる凶器に変わる。とくに近年の薄型ノートPCの多くは、ストレージがマザーボードに直接はんだ付けされている。SSDが寿命を迎えることは、数千円の部品交換で済む問題ではなく、端末全体の死を意味する。さらに、データベースのサイズが200MBを超えると30分から1時間程度でCodex CLI自体がクラッシュし始めるという二次的な障害も報告されており、ストレージの圧迫はソフトウェアの動作安定性をも破壊する。
AIエージェントの実装においては、生成されるコードの質や推論の精度はもちろん、ホストマシンのリソースを安全に扱うための品質管理も同時に問われる。ローカル環境で常時稼働するツールが急速に普及する現在、ソフトウェアの動作がハードウェアの寿命という物理的な制約に直結しているという事実を、開発側もユーザー側も強く意識する必要がある。