ハクソク

世界を動かす技術を、日本語で。

Codexのログ記録バグがローカルSSDにTB単位のデータを書き込む可能性

2026年6月22日原文(github.com)

概要

  • CodexのSQLiteログが大量データを書き込み、SSDの寿命を大きく消費
  • TRACEレベルのグローバルログが主な要因で、約96%の無駄なログが発生
  • 書き込みアンプリフィケーションにより、実際の書き込み量はDBサイズ以上
  • ログフィルタリングや閾値調整などの改善策を提案
  • 関連する既知の問題や議論も多数存在

CodexによるSQLiteログの大量書き込み問題

  • Codexは ~/.codex/logs_2.sqlite などのSQLiteログファイルへ 大量のデータ書き込み を継続的に実施
  • 21日間の稼働で 37TB の書き込み、年間換算で 約640TB、SSDの寿命を1年未満で消費する恐れ
  • 主な書き込み源は TRACEレベルのグローバルログ や OpenTelemetryのミラーログ
  • 1TB SSDの場合、 年間640回の全ドライブ書き込み に相当し、消耗が著しい

ログ内容と主な発生源

  • 保持されているログの 約70.7%がTRACEレベル、 25.3%がOpenTelemetry系INFOログ
  • 主なTRACEソースは inotifyイベント、 tokio-tungstenite の内部ロジック、 WebSocket/SSEのペイロードログ
  • INFOログは OpenTelemetryイベントの繰り返し が大半
  • 例： inotify event: ... mask: OPEN, name: Some("ld.so.cache") など高頻度の冗長なイベント

書き込みアンプリフィケーションの実態

  • 15秒間で 36,211行 が挿入されるが、保持行数は変わらず
  • 挿入→インデックス→WAL書き込み→プルーニング の繰り返しで、実際の書き込み量はDBサイズを大幅に上回る
  • SSDの実効寿命低下の主因

原因の分析

  • SQLiteフィードバックログシンクがグローバルTRACEデフォルト でインストールされている
  • 依存ライブラリや内部ログ、プロトコルペイロードまで全て保持対象となり、無駄なデータが大量蓄積
  • フィルタ設定が不十分で、 低価値ノイズログ も全て記録

改善提案

  • グローバルTRACEレベルの使用中止 （デフォルト閾値引き上げ）
    • 依存ライブラリやノイズの多いターゲット（log, hyper_util, tokio-tungstenite, inotify, OpenTelemetry SDK）をフィルタリング
  • WebSocket/SSEの生ペイロードは記録せず、要約情報のみ保存
    • イベント種別、継続時間、成否、トークン使用量、バイト長など
  • codex_otel.log_only / codex_otel.trace_safeのミラーイベントも原則保持しない
  • ログDBのグローバルなサイズ/書き込み上限を設定
    • スレッド単位ではなく、全体で制御
  • sqlite_logs_enabled = false などの無効化オプションも有用だが、本質的な解決はフィルタリング強化

関連する既知の問題・議論

  • TRACEログがRUST_LOGを無視してWALに大量書き込み （#17320）
  • Codex Desktopでlogs_2.sqlite/WALが急拡大 （#24275, #26374, #22444）
  • Codexのアイドル時でも高いI/O負荷 （#20563, #27020）
  • goals_1.sqliteでの書き込みアンプリフィケーション （#27911）
  • 長時間スレッドでのメモリ・TRACEログ負荷によるアプリの不安定化 （#21134, #12969）

まとめ

  • Codexの現状デフォルト設定では SSD寿命を著しく損なうリスク
  • TRACEレベルのグローバル記録をやめ、ノイズログをフィルタリング することが最優先
  • ログDBサイズ制限やペイロード要約化 など、運用面・技術面双方の対策が必要

Hackerたちの意見

Codexって、スロップウェアの中でも特に悪名高い例だよね。マックでウィンドウを表示させてるだけで、GPUの使用率が100%になって、スピナーのメッセージが出るんだ。MBP M5でスピナーメッセージが出ると、GPU使用率が100%になるってことだよ！だから、モデルを待ってる時間（ほとんど90%の時間）中は、ファンがうるさくなるんだよね（バッテリーで使うのは注意してね）。この問題はGitHubにあって、もう6ヶ月近く放置されてる。多分、Vibeのコードがリリースされた時からだろうね。自分で直したいけど、何かの理由でクローズドソースなんだ。どのモデルがいいかとか、Vibeコーディングが可能かどうかについての議論はたくさんあるよ。資金も潤沢で、スタッフも揃ってるモデル制作会社がVibeコーディングで何ができるかを見てほしい。こんなにひどいミス（CEOが「コーディングに集中してる」って言ってる時点で）を犯すってことは、会社に何か本当に壊れてるものがあるってことだと思う。ポリマーケットでは、彼らがすぐにリーディングモデルを持つとは誰も思ってないよ。悲劇だね。世界にはAnthropicに対抗する競争が必要なんだ。

└

それはずいぶん前に修正されたはずだよ、同じバグのことを考えてるならね。Codexのウィンドウが開いてる間、ずっと無限ループにハマってたんだ。

└

Codexはスロップウェアの中でも特に悪名高い例だよね。うわ、Claudeコードもそこにあるのを忘れないでね。

└

サービスありがとう。Claude Codeの災害の後、Codexを試してみようかと思ったけど、どっちもマシンに入れなくても大丈夫そうだな。

└

Codexだけじゃなくて、macOSのChatGPTアプリを数時間開いておくこともできないんだ。時間が経つにつれて60GBのRAMを消費して、全てのアプリがクラッシュしちゃう。驚きだよ。それに、GoogleのAIスタジオもブラウザで使えない。CPUを100%使っちゃうから。全部自分でアプリ作らなきゃいけないの？

└

もしAIが10倍で、AGIやASIに近づいているなら、どうしてCodexやClaude Code CLIがまだこんなにゴミなんだろう？この「エージェントAI革命」でとっくに解決してるはずじゃない？「頑張ってるから待ってて」なんて言ってるわけないよね、まさか「努力が多すぎる」なんて？

└

このソフトウェアは最悪だった。トークンをめっちゃ消費するし、失敗することが多い。ブラウザプラグインを使おうとすると、ほとんどの場合「プラグインが使えません」って言われる。動くときも、ボタンをクリックするのに数分かかる。使えないワークフローだよ。アルファチャンネル付きのpngを生成してって頼むと、できないって。代わりにクロマキーの画像を出力して、クロマキーを除去するPythonスクリプトを生成するけど（失敗）、次にJSスクリプト（これも失敗）。で、5時間の枠が終わっちゃう。もし広告通りに動いてくれたら、すごいツールなのにってイライラする。

└

私も同じようにイライラしてPiに切り替えたけど、全く不満はないよ。

└

スピナーのメッセージがMBP M5で100%のGPU使用率を引き起こす！！これは、いろんなソフトウェアで共通のChromiumの問題みたい。GitHubもスピナーで同じ問題が起きてるし、VSCodeでもそうだよ。

└

それは悲劇だね。世界には競争が必要だと思う。でも、サム・アルトマンの会社がクロードの代わりになるのは最後の選択肢だな。オープンモデルを全部試してみる方がいい。

誰かがXで一時的な回避策を投稿してたよ。sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;" それと、ノートパソコンのsqliteファイルでVACUUM FULLを実行したら、27GBからたったの73MBに縮小できたよ。

└

本当の解決策は、使うのをやめてPiに切り替えることだね。

Hacker Newsで議論の続きを見る