OpenAI Codex CLIに未修正のバグ、SSDに年間約640TBの書き込みが発生し寿命を縮める恐れ

2026年6月23日 05:40

OpenAIの「Codex CLI」において、開発者のローカルSSDに対して年間約640TBに及ぶ大量のデータをサイレントに書き込む未修正のバグが存在することが明らかになった。この書き込み量は、一般的な1TBのコンシューマー向けSSDの設計寿命（総書き込み容量）を超える規模である。現時点でOpenAIからの公式な回答や修正パッチは提供されておらず、継続して実行している場合はSSDに不可逆的なダメージを与えている可能性がある。

■ドライブの寿命を縮める書き込みペース

この問題は、2026年6月14日にコミュニティの開発者「1996fanrui」によってGitHubのIssue #28224として報告された。同開発者が高いディスクアクティビティに気づき調査したところ、Codexが保持するローカルのSQLiteデータベース（~/.codex/logs_2.sqlite）が原因であることが判明した。21日間の稼働で、SSDはCodexだけで約37テラバイト（TB）の書き込みを吸収していた。これを年間換算すると、約640TBに達する。一般的な1TBのコンシューマー向けSSDのメーカー保証寿命（総書き込み容量：TBW）は、その全期間を通じて約600TBWである。Codexの書き込みペースでは、わずか1年未満でドライブの保証寿命を使い果たす計算になる。

■手遅れになるまでダメージが不可視である理由

このバグが開発者にとって特に危険なのは、標準的な監視ツールでは明らかな痕跡が残らない点にある。SQLiteデータベースは、行を挿入すると同時に同じ速度で古い行を削除（プルーニング）している。Issue #28224の15秒間のサンプルでは、ロガーが36,211行を挿入した一方で、保持された総行数は681,774行とほぼ一定に保たれていた。そのため、「du」などのコマンドで表示される論理的なファイルサイズはほとんど変化せず、ファイルシステムの容量制限を監視していても異常に気づくことはできない。しかし、物理的なSSDの内部では異なる事態が起きている。

このSQLiteデータベースはWAL（Write-Ahead Logging）モードで動作しており、定期的なチェックポイント処理でメインデータベースにマージされる前に、すべての書き込みが個別の「-wal」ジャーナルファイルに追加される。毎分何万回もの挿入・削除サイクルが実行されると、WALのチェックポイント処理によって、論理的なデータサイズを大幅に上回る物理的なフラッシュ書き込みが発生する。

これは「ライトアンプリフィケーション（書き込み増幅）」と呼ばれる現象であり、実際のNANDフラッシュセルに書き込まれるバイト数が論理的な書き込み負荷の数倍に達するため、このバグが単なるノイズにとどまらず、ハードウェアに物理的な危険を及ぼす原因となっている。このダメージを検出する唯一の信頼できる方法は、ドライブ自体のSMARTデータを読み取ることである。Linux環境でNVMeドライブを使用している場合は、「sudo smartctl -a /dev/nvme0 | grep \"Data Units Written\"」コマンドで物理的な総書き込み量を直接確認できる。SATA SSDの場合は、「Total_LBAs_Written」というSMART属性が同様の役割を果たす。

■SQLiteログバグの技術的背景

根本的な原因は、Codexの内部ログアーキテクチャにおけるデフォルト設定の誤りにある。SQLiteのフィードバックログ出力先が「Targets::new().with_default(Level::TRACE)」と設定されており、すべてのログ対象が「TRACE」レベルに設定されている。これはログフレームワークの中で最も詳細な設定であり、通常は深いデバッグセッションのために予約されるもので、製品版のソフトウェアで出荷されるべきものではない。

TRACEレベルでは、ロガーは生のWebSocketやSSE（Server-Sent Events）のペイロードボディ、passwdやld.so.cacheのオープンといった日常的なファイルシステムイベント、tokio-tungsteniteやhyper_utilなどの依存ライブラリの内部状態、さらにはミラーリングされたOpenTelemetryイベントまで、あらゆる情報をキャプチャする。

Issue #28224の分析によると、TRACEレベルのエントリだけで保持された書き込みバイト数全体の約70.7%を占め、OpenTelemetryのミラーイベントがさらに25.3%を占めている。これら2つのカテゴリを排除するだけで、本来の診断機能を維持したまま、書き込み量の約96%を削減できる。さらに悪いことに、このロガーはRustアプリケーションがログの冗長性を制御するために使用する標準の環境変数「RUST_LOG」を完全にバイパスしている。

このバイパス問題は、2026年4月10日に報告された別のGitHub Issue #17320で最初に文書化されていた。ユーザーや開発者が環境変数に「RUST_LOG=warn」（警告以上のメッセージのみを出力する設定）を指定していても、SQLiteへの出力は最大のTRACEレベルで書き込みを継続するため、標準の制御メカニズムが機能しない。結果として、最大レベルでログを書き込み、ユーザーの制御をバイパスし、自己削除機能によってファイルサイズを小さく見せかけ、WALチェックポイントによって物理的な書き込み負荷を増幅させるという、最悪の組み合わせが実現してしまっている。

■4月から放置されている既知のパターン

この問題が記録されたのは、Issue #28224が最初ではない。2026年4月10日には、「TRACEログがRUST_LOGを無視することによる、ストリーミング中の過剰なSQLite WAL書き込み」と題されたGitHub Issue #17320が報告されていた。これは今回の報道から10週間以上前のことである。同Issueでは、ストリーミング中に約5 MiB/s、ピーク時には16 MiB/sに達する書き込み速度が記録されている。Codexのリポジトリ全体で、少なくとも8件の異なるGitHub Issueが、同じ根本的なログ動作に起因する様々な症状を報告している。

OpenAIが2026年6月に公開したCodexの変更履歴には、データベースの破損や初期化エラーに対処するSQLiteの信頼性修正が含まれているが、SSDの劣化を引き起こすTRACEレベルの書き込み速度問題に対処したものは存在しない。

本記事の公開時点で、Issue #28224が報告されてから8日が経過している。OpenAIは公式声明、公式な回避策、パッチのいずれも発表していない。Hacker Newsでこのスレッドを取り上げた開発者たちは、この無反応な対応を「不可解（baffling）」と呼び、ある実務者は「OpenAIにはGitHubのIssueをリアルタイムで監視し対処する内部ツールがないのだろうか」と疑問を呈している。

■最も高いリスクに直面しているユーザー

すべてのCodexユーザーが等しくリスクにさらされているわけではない。Issue #28224を報告した開発者は、21日間にわたりマシンを常時稼働させており、これが最もリスクの高いシナリオである。しかし、継続的に使用するパターンであれば、どのような状況でもリスクは規模に応じて増大する。特に、最新のノートPCを使用している個人の開発者は深刻な影響を受ける。

現在のウルトラブックや薄型軽量ノートPCのほとんどは、NVMeドライブが基板にハンダ付けされて出荷されている。ハンダ付けされたドライブが寿命を迎えた場合、60ドル（約9,700円、1ドル=162円換算）の代替品と交換することはできず、マシン全体を買い替える必要がある。暴走したログプロセスによる寿命の損失は不可逆的であり、保証の対象外となる可能性もある。

また、WindowsユーザーはLinuxやmacOSユーザーよりも厳しい状況にある。2週間前に報告されたGitHub Issue #27020によると、Windows上のWSL2環境において、同じCodexプロセスが持続的な高ディスクI/Oを発生させ、WindowsタスクマネージャーでCodexセッション中にディスク使用率が100%に達することが報告されている。Windows向けには、後述する「/tmp/」へのシンボリックリンクのような回避策は確認されていない。

さらに、SSDの摩耗に加えて新たな二次的リスクも浮上している。2026年6月20日に報告された別のIssueによると、logs_2.sqliteのファイルサイズが約200MBを超えると、Codex CLIがアクティブな使用から30〜105分以内にセッションの途中でクラッシュし始めるという。回避策を適用せずに数週間から数ヶ月間Codexを実行し続けている開発者の場合、ツールはすでにこの閾値に近づいている可能性がある。

■今すぐ実行できるCodex CLIの回避策

OpenAIがパッチをリリースするまでの間、LinuxおよびmacOSユーザーには一時的な回避策がある。「~/.codex/logs_2.sqlite」から「/tmp/」へのシンボリックリンクを作成することで、すべてのSQLiteログの書き込み先を物理SSDではなくRAM（tmpfs）にリダイレクトできる。/tmp/はRAMを基盤としているため、データがフラッシュストレージに到達することはなく、再起動するたびに消失する。このログファイルには会話データや重要な状態は含まれていないため、消失しても問題はない。

Hacker Newsのコミュニティでは、別の方法として、logsテーブルへのすべての挿入をブロックするSQLiteトリガーを作成し、ファイルをリダイレクトすることなく書き込みを完全に防ぐ方法も報告されている。また、既存のlogs_2.sqliteファイルに対して「VACUUM」コマンドを実行することで、あるユーザーの環境ではデータベースが27GBから73MBに縮小し、すでに消費されていたストレージ容量を回収できたという。

ドライブがすでにこのバグによるダメージを受けているかどうかを確認するには、回避策を適用する前にSMARTデータを読み取る必要がある。Linux（NVMe）では「sudo smartctl -a /dev/nvme0 | grep \"Data Units Written\"」を実行し、SATA SSDでは「Total_LBAs_Written」属性を確認する。基準となる数値を記録し、Codexをアイドル状態で1時間実行した後に再度カウンターを読み取る。その差分がギガバイト単位であれば、システム上でバグが有効になっている。なお、Windowsユーザー向けには、シンボリックリンクによるアプローチと同等の回避策は現時点で確認されていない。

■AI開発ツールとサイレントなハードウェアリスクという大きな構図

今回のインシデントは、従来のソフトウェアには直接的な類似例がないカテゴリーのリスクを浮き彫りにしている。バックグラウンドで常時稼働し、ローカルファイルシステムへの高度なアクセス権を持つAIコーディングエージェントは、目に見える警告やユーザー向けのエラー、標準的な監視ツールがフラグを立てるようなログエントリを一切残さずに、物理ハードウェアを損傷させる可能性がある。

OpenAIはCodexのローカルアクセス権限を積極的に拡大してきた。2026年4月には、macOS上での完全なデスクトップ操作機能が追加された。同時期には、開発者の画面のスクリーンショットを定期的にキャプチャする「Chronicle」機能も導入されている。これほど高度なローカルアクセス権を持つエージェントが、自身のログ冗長性制御をバイパスするロガーを搭載して出荷されていることは、ユーザーが通常監査することを想定しない品質管理上の欠陥を示している。

Issue #28224から得られる具体的な教訓は、Codex CLIを実行している場合はドライブのSMART書き込みカウンターを確認することである。そして、2026年4月から確認されていたバグに対して6月になっても修正が提供されないというパターンから得られる教訓は、ツールが急速にリリースされ、ハードウェアへの影響がサイレントに発生する場合の、体系的な品質保証のあり方についてである。

■注目ポイントQ&A

●OpenAI Codex CLIを実行している場合、私のSSDは損傷していますか？

数日間または数週間にわたって継続的に実行していた場合、損傷している可能性があります。確認するには、Linuxではsmartctl、WindowsではCrystalDiskInfoなどのツールを使用して、SSDの総書き込みバイト数（SMARTデータ）を確認してください。Codexを1時間アイドル状態で実行する前後の数値を比較し、ギガバイト単位で増加している場合はバグが有効になっています。SSDの摩耗は不可逆的です。

●このCodex CLIのSSDバグとは何ですか？また何が原因ですか？

Codex CLIがSQLiteのログ出力をグローバルな「TRACE」レベル（最も詳細なログ設定）で実行していることが原因です。これにより、不要な内部イベントやテレメトリデータが大量に書き込まれます。さらに、ログの冗長性を制御する標準の環境変数RUST_LOGをバイパスするバグも重なっています。SQLiteのWAL（Write-Ahead Logging）モードによる書き込み増幅現象も加わり、実際のファイルサイズ以上に物理的なSSDへの書き込みが発生し、寿命を急速に縮めています。

●ドライブを保護するために、今すぐできる対策はありますか？

LinuxまたはmacOSユーザーは、~/.codex/logs_2.sqliteを/tmp/logs_2.sqliteにシンボリックリンクすることで、ログの書き込み先をRAM（tmpfs）に変更できます。これにより物理SSDへの書き込みを防げます。ログファイルには会話履歴などの重要なデータは含まれないため、再起動時に消失しても問題ありません。Windowsユーザー向けの同等の回避策は現時点で確認されていません。公式パッチのリリースについてはGitHubのIssue #28224を監視してください。

●同様のバグは他のAIコーディングツールでも発生する可能性がありますか？

可能性はあります。バックグラウンドで常時稼働し、ローカルに診断ログを書き込み、ログの冗長性設定の監査が不十分な開発ツールであれば、同様のリスクを抱えることになります。今回の具体的なメカニズム（RUST_LOGを無視するTRACEレベル設定とSQLite WALの組み合わせ）はCodex特有ですが、AIエージェントがユーザーに気づかれずにハードウェア資源を消費するという広範なパターンは、共通の懸念事項です。

元記事: OpenAI Codex CLI Bug Silently Writes 640 TB/Year to Your SSD: No Patch