OpenAI Codexのコマンドラインインターフェース（CLI）に、データ書き込み過多に関する重大なバグが発生しており、SSDの物理的な寿命を直接脅かしている。技術レポートによると、ログ記録システムの設定ミスにより、ソフトウェアが年間最大640TBものデータをドライブに書き込む可能性があり、これは現在市販されているほとんどのSSDの負荷容量をはるかに超える。
テクノロジー業界から衝撃的な発見があった。
この問題は、6月中旬にGitHubユーザーの1996fanruiがシステム上で異常に高いディスクアクティビティに気づいたことから発覚しました。徹底的な分析を行った結果、OpenAI Codexがパス~/.codex/logs_2.sqliteにあるローカルSQLiteデータベースにデータを継続的に書き込んでいることが分かりました。
このOpenAI Codexの脆弱性を放置すると、ドライブの保証期間が1年以内にすべて切れてしまう可能性がある。
実際のデータによると、21日間連続稼働させた後、ハードドライブには約37テラバイト（TB）のデータが書き込まれた。これを年間換算すると、約640テラバイト（TB）に達する。参考までに、一般的な1TB SSDの総書き込みバイト数（TBW）は約600TBである。したがって、このソフトウェアのバグだけでも、新品のSSDの寿命を12ヶ月以内に完全に奪ってしまう可能性がある。
技術的な原因：ログレベルが制御不能になった場合。
あなたへのおすすめ
問題の核心は、OpenAIがエンドユーザーへのリリース時にうっかり見落としてしまったと思われるログ設定にある。CodexのSQLite応答システムは、デフォルトでグローバルTRACEレベルで動作する。これはプログラミングにおいて最もノイズの多いレベルで、ごく小さなイベントさえもログに記録される。
このシステムは、生のWebSocketパケットから、システム設定ファイル（passwdやld.so.cacheなど）を開くといった一般的なファイルシステムイベントまで、あらゆるものをログに記録します。特に、このソフトウェアは標準の環境変数RUST_LOG無視するようで、ユーザーは従来の方法でログレベルを簡単に下げることができません。
さらなる分析の結果、記録されたデータの約71%はTRACEレベルのノイズで構成されており、一般ユーザーにとって実用的な診断価値は全くないことが明らかになった。
増幅効果を書き込む
問題はログファイルのサイズ増加だけではなかった。この場合、SQLiteデータベースの特性そのものが深刻な書き込み増幅を引き起こした。単にデータを書き込むのではなく、システムは1分間に数万回もの挿入と削除操作を実行していたのだ。
物理的に、SSD上のフラッシュメモリブロックは、これらの操作を実行するために常に消去と書き換えを行う必要があります。そのため、メモリチップが実際に処理しなければならないデータ量は、オペレーティングシステムに表示されるファイルサイズの何倍にもなります。これが、このエラーがソリッドステートストレージデバイスにとって非常に危険な理由です。
ユーザー向けの暫定的な回避策
あなたへのおすすめ
OpenAIは最近SQLiteの安定性に関するアップデートをリリースしましたが、データ書き込み速度が異常に速いという問題は未解決のままです。公式パッチがリリースされるまでの間、LinuxおよびmacOSユーザーは以下の方法でハードドライブを保護することができます。
シンボリックリンク (symlink) を使用して、ファイル~/.codex/logs_2.sqliteを/tmp/ディレクトリにリダイレクトします。 /tmp/ディレクトリは通常、RAM (tmpfs) にマッピングされるため、ログデータは SSD ではなく RAM に書き込まれます。このファイルには重要な会話データが含まれていないため、コンピュータの再起動時にログデータが失われても、ユーザーエクスペリエンスには影響しません。
専門家は、Codex CLIユーザーに対し、ストレージデバイスへの不必要な物理的損傷を避けるため、ドライブのアクティビティを直ちに確認し、データリダイレクト対策を講じることを推奨しています。
出典: https://baodanang.vn/loi-openai-codex-cli-am-tham-bao-mon-ssd-nguy-co-hong-o-cung-trong-chua-day-mot-nam-3341429.html