CodexのロギングバグによりローカルSSDへTB単位の書き込みが発生し、SSD寿命を急速に消耗する可能性

 (github.com/openai)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • CodexがローカルのSQLiteフィードバックログDBへ継続的に大量のデータを書き込み、あるユーザー環境では21日稼働後にメインSSDへ約37TBが書き込まれた
  • これを年換算すると約640TBで、1TB SSD基準では年間約640回の全ドライブ書き込みに相当し、一部のコンシューマー向けSSDの保証寿命（約600 TBW）を1年以内に使い切る可能性がある
  • 保持されている行は約50万件にすぎない一方、AUTOINCREMENTカウンタは55億IDを超えており、保持行数と累積挿入IDの間には約1万倍の差が存在する
  • 原因はSQLiteフィードバックログシンクがグローバルTRACEデフォルト（Targets::new().with_default(Level::TRACE)）に設定され、依存関係内部のログや大容量のrawプロトコルペイロードまで含めて永続記録していたため
  • 2026年6月22日に2つのPRがマージされ、約85%のログが遮断されたことでイシューは終了した

主要な症状と影響範囲

  • Codexが次のファイルへ継続的に大量書き込みを発生させる
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • 21日稼働後にメインSSDへ約37TBが記録され、プロセス／ファイル単位の調査でCodexのSQLiteログが主要な継続書き込み元であることが確認された
  • 年間約640TBに相当し、1TB SSD基準では年間約640回のフルドライブ書き込みレベル
  • 一部のコンシューマー向けSSDは約600 TBW等級のため、保証書き込み寿命を1年未満で使い切る可能性がある

証拠データ

  • Evidence1 — 書き込み増幅（write amplification）

    • 現在のlogs_2.sqliteファイルサイズ: 1.2 GiB
    • 現在保持されている行数: 506,149件
    • 累積割り当てrow id: 5,543,677,486件
    • 保持行数（約0.5M）と累積挿入ID（55億超）の間に約1万倍の差があり、WAL・インデックス・プルーニング・チェックポイント・ページ再書き込み・デバイス単位の増幅を除いても、過去ログのchurnは10TB超と推定される

  • Evidence2 — レベル／ターゲット分布

    • 保持行数681,774件、推定保持ログ内容は約1,035.6 MiB
    • レベル別比率: TRACE 70.7%、INFO 25.7%、DEBUG 3.0%、WARN 0.6%
    • 最大のtarget+levelペア
      • codex_api::endpoint::responses_websocket (TRACE) 527.4 MiB
      • codex_otel.log_only (INFO) 141.2 MiB
      • codex_otel.trace_safe (INFO) 121.2 MiB
      • log (TRACE) 97.4 MiB
    • 上位の発生源は、グローバルTRACEログ、ミラーされたテレメトリログ、raw websocket/SSEペイロード記録が大半を占める
    • codex_otel.log_only + codex_otel.trace_safe が追加で25.3%を占めており、このカテゴリをフィルタリングするとサンプル基準で保持ログバイトの約96%を削減可能
    • 最も頻出するTRACEソース（target=log）には、inotify event（例: ld.so.cache 128,764回）、tokio-tungstenite内部呼び出し、WouldBlock など低レベル項目が多数含まれる

  • 書き込み増幅の測定

    • 15秒サンプルでは保持行数は681,774件のまま変化せず、約36,211件の行が挿入された
    • 挿入→インデックス化→WAL記録→プルーニングが繰り返されるinsert-and-pruneパターンにより書き込み増幅が発生している

推定原因

  • SQLiteフィードバックログシンクがグローバルTRACEデフォルト（Targets::new().with_default(Level::TRACE)）で導入されていた
  • その結果、依存関係／内部ログや大容量のrawプロトコルペイロードまで、すべてのターゲットがTRACEレベルで永続保存されていた

提案された修正方針

  • フィードバックログは維持しつつ、デフォルトの永続保存範囲を狭めるべき
    • SQLiteフィードバックログシンクでグローバルTRACEを使わない
    • target=log、hyper_util、tokio-tungstenite内部、inotifyスパム、低レベルのOpenTelemetry SDKログなど、価値の低いノイズのしきい値を引き上げるか除外する
    • raw websocket/SSEペイロード全体を保存する代わりに、要約（イベント種別、所要時間、成功／失敗、トークン使用量、ペイロードのバイト長）を保存する
    • codex_otel.log_only / codex_otel.trace_safe のミラーイベントは、デバッグに有用な場合を除き保存を避ける
    • スレッド単位の上限だけでは不十分なため、グローバルなログDBサイズ／書き込み上限を追加する
  • sqlite_logs_enabled = false のようなオプションも有用だが、根本的な解決はより良いデフォルトフィルタリングにある

マルチプラットフォームでの再現報告

  • macOS

    • macOS 15.7.7 / Codex 26.616.51431環境で、logs_2.sqlite は113M、MAX(id)=34,277,360 に対して保持行数31,405件、60秒サンプル2回で約毎秒60回の書き込みが確認された
    • 1〜2時間のセッション中に codex プロセスが約50GBを書き込んだ事例も報告された

  • Windows

    • Windows Codex Desktop（codex.exe app-server --analytics-default-enabled）で、RUST_LOG=warn および明示的なtrace設定がないにもかかわらずTRACE行が継続挿入されていた
    • 保持行数は約71k、sqlite_sequence の logs 値は1,850万超で、過去に多数のinsert/prune churnがあったことを示す
    • 10分間の分布ではTRACEが1,812行で、上位TRACEターゲットには codex_api::endpoint::responses_websocket（3.5MB超）、codex_api::sse::responses が含まれる
    • 期待される動作: RUST_LOG=warn の場合、依存関係／内部TRACEや大容量ペイロードを継続保存しないこと

追加リスクと暫定的な緩和策

  • データ損失リスク

    • ディスクが満杯の状態で再起動すると、Linuxでログインに失敗する可能性がある
    • Codexの/goalモードがディスク容量確保を試み、ファイル／フォルダを削除してデータ損失が発生する可能性がある

  • 暫定緩和スクリプト

    • 実行中のWALをトリミングする trim-codex-wal.sh（PRAGMA wal_checkpoint(TRUNCATE) を使用）。cronで15分ごとに実行可能
    • ログ／WALファイルを削除した後、Codex関連プロセスへSIGTERM→SIGKILLを送ってディスク容量を即座に確保する fix-codex-wal.sh
    • logs テーブルへの挿入を無視するSQLiteトリガー（block_log_inserts）を追加するとWALの増加が止まる。元に戻す場合は DROP TRIGGER IF EXISTS block_log_inserts
      • VACUUM はDBを書き直すため、大容量ファイルでは一時的に大きな書き込みを発生させる可能性がある。そのため、トリガー追加後にWAL増加の停止を確認してから DELETE / VACUUM を実行することが推奨される
      • 非公開のSQLiteスキーマを変更するため、今後のCodexアップデート／マイグレーションでテーブル再作成やトリガー削除などが起きる可能性がある
    • 恒久修正までSSD損傷を防ぐため、このDBをramdisk上に置く方法も提示されている

解決と終了

  • 2026年6月22日に2つのPRがマージされ、約85%のログ削減が実現したため、このイシューは完了扱いとなった
    • すべてのResponses WebSocketイベントのロギングを停止 (#29432)
    • 永続ログからノイズターゲットをフィルタリング (#29457)
  • 別途提案されたパッチでは、グローバルTRACEの代わりに INFO+ をデフォルト保存とし、codex_otel.log_only・codex_otel.trace_safe・hyper_util・log・opentelemetry_sdk などを WARN+ へ引き上げる
  • 修正内容は rust-v0.142.0 としてリリースされた

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • Codexは slopware の悪名高い事例の一つだと思う
    macOSではウィンドウを表示しているだけでも、スピナーのメッセージを表示するために GPU を 100% 使う
    MBP M5でスピナーメッセージだけで GPU 100% になり、モデルを待っている時間の大半でファンが大きく回るので、バッテリー駆動時は注意が必要
    この問題は GitHub に上がってからほぼ6か月経っていて、おそらくバイブコーディングで作られたガラクタがリリースされて以降ずっとそうだったのだと思う
    自分で直したくても、理由は分からないがクローズドソースなので不可能
    どのモデルがより良いか、バイブコーディングが可能かについては議論が多いが、資金・人員・モデル能力が最も豊富な企業の一つでも、バイブコーディングでできる水準はこの程度なのだと思う
    CEO がすでに「コーディングに注力する」と明言している状況で、このような深刻なミスは社内で何かが本当に壊れているというシグナルに見えるし、Polymarket でも OpenAI が近く先行モデルを出すと見ている人はほとんどいない
    世の中には Anthropic の競争相手が必要なので悲劇的だ

    • Claude Code もすぐ隣にいるのだから、slopware の事例から外してはいけない
    • AIで10倍の生産性が出ていて AGI や ASI に近いのなら、Codex や Claude Code CLI のような製品がどうしていまだにここまでひどいのか分からない
      「エージェント型AI革命」がすでにこうした問題を解決しているべきではないかと思う
      まさか内部で「処理中なので待ってほしい」とか「難しすぎる作業」などと言っているわけではないだろうし
    • 基本的にすべてをオープンソースで公開していた組織で働いていたとき、サイドプロジェクトも含めて何かをクローズドのままにしておく理由は一つしかなかった。恥だ
      誰もひどいコードベースの表の顔にはなりたくない
      そのコードで法外な価格を正当化しているなら、その負担は3倍くらい大きいはずだ
    • Codex だけでなく、macOS の ChatGPT アプリ も数時間開きっぱなしにしていると、時間とともに RAM を 60GB まで食い尽くして他のアプリを全部殺してしまう
      理解できない
      ブラウザで Google AI Studio を使おうとしても CPU を 100% 使う
      結局すべて自前でアプリ化しないといけないのかと思う
    • 初期には世の中に ChatGPT の競争相手として Anthropic が必要だと言われていたが、今では完全に一周回った

  • X にこの問題の 暫定回避策 が上がっている[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    またノートPCでその sqlite ファイルに VACUUM FULL を実行したところ、27GB から 73MB に減った[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • 今回も データベースレベルのルール が一日を救った
    • 本当の解決策は使用をやめて Pi に乗り換えることだ

  • みんな OpenAI を批判していて、それはもっともだが、Claude Code と違って Codex は公式にカスタマイズ可能 だという点は思い出しておく価値がある: https://github.com/openai/codex
    パッチを当てるのもかなり簡単だ

    • それは CLI であって、ここで話している独占的な Codex アプリ のことではない

  • 衝撃的だ
    issue が立ってから1週間経つのに、私には OpenAI はただ沈黙しているように見える
    こういうベンダーはこうした問題に非常に敏感だと思っていたので理解できない
    当然 GitHub の潜在的な issue を監視して修正案を提案する複数のエージェントを付けているのだろう？ …そうだよね？
    自分たちのツールを回して GitHub issue をリアルタイムで直させるのは、当然ささいなことのはずなのに

    • OpenAI は issue 修正がかなり苦手なようだ
      個人的に好きな事例は #2472 で、GPT-5 のローンチステージで「修正」したとデモしていたが、チケットはまだ開いたままで、その「修正」もマージされていない
      この事実を指摘した元の記事は https://blog.tymscar.com/posts/openaiunmergeddemo/ で、issue は https://github.com/openai/openai-python/issues/2472 だ
    • 同じ問題に関する GitHub issue が 4月から あった
      Codex をかなり使っていて、性能（UX と出力）にはとても満足しているが、この問題をまだ直していないのは理解しがたい

  • この問題は 修正されたようで[0]、次のリリースに入るようだ
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • バイブコーディングは「素早く動いて壊せ」をまったく別のレベルへ引き上げる

    • 今うちの会社では、誰かの バイブコーディングしたゴミ が深刻におかしくなって、大規模障害対応を抱えている
    • もう壊せるものもだんだん底をついてきている
    • 技術的負債がなければ、バイブコーディング はたいていプロトタイピングには有用だ
      実製品では本物のソフトウェアエンジニアが置き換えられることは決してないだろう

  • 少し話題から外れるが、こうした会社はリポジトリのルートフォルダを Claude.md や copilot.md で汚すのをやめるべきだ
    一度集まって docs/llm/* のようなよく知られたフォルダ構成を決めるべきだ

  • 昨年末、Claude Code が遅延でひどかったとき、OpenAI はほとんど手にしていた勝利を逃した
    最近では Codex は起動した瞬間から入力遅延があり、Claude Code は時々固まるとはいえ、たいていはキーを押せば……文字通り……押した通りに表示される

    • 私の場合はちょうど逆だ
    • Claude Code はほとんど使いものにならないレベルだと感じる
      数語以上入力するときは、いつも neovim で入力しなければならない

  • これは実際かなり典型的なミスだ
    すべてに 追跡/デバッグログ を有効にしたままリリースしてしまったのであり、面白いのは影響が一般的な形では現れていないことだ
    昔なら開発者が trace レベルのロギングを有効にして、アプリが壊滅的に遅くなり、次のアップデートですぐ直していただろう。しかし今はメモリ・CPU速度・ディスク速度が圧倒的に向上していて、そういう形で即座に露呈しない地点まで来ているのが狂っている

    • エージェント処理がサーバー側で行われるので、薄いクライアントが ローカルリソース を食い尽くしてもよいという発想も一因だ

  • 誰かこの元気いっぱいのスタートアップに トークン を寄付してあげてほしい。助けが必要そうだ