Codexのロギングバグにより、ローカルSSDにTB単位のデータが書き込まれる可能性

openai / codex パブリック 通知 通知設定を変更するにはサインインする必要があります フォーク 13.7k スター 92.6k Codex SQLiteフィードバックログは年間約640TBを書き込み、SSDの耐久性を急速に消費する可能性があります #28224 新規イシュー コピーリンク 新規イシュー コピーリンク オープン オープン Codex SQLiteフィードバックログは年間約640TBを書き込み、SSDの耐久性を急速に消費する可能性があります #28224 コピーリンク ラベル CLI Codex CLIに関連するイシュー Codex CLIに関連するイシュー バグ 何かうまくいかない 何かうまくいかない パフォーマンス 説明 1996fanrui が 2026年6月14日 にオープン イシュー本文のアクション Codex SQLiteフィードバックログは年間約640TBを書き込み、SSDの耐久性を急速に消費する可能性があります イシュー Codexは、ローカルのSQLiteフィードバックログデータベース（~/.codex/logs_2.sqlite, ~/.codex/logs_2.sqlite-wal, ~/.codex/logs_2.sqlite-shm）に大量のデータを継続的に書き込んでいます。 私のマシンでは、約21日間の稼働後、メインSSDには約37TBが書き込まれていました。プロセス/ファイルレベルのチェックでは、Codex SQLiteログが主な継続的書き込み元であることが示されています。これは年間およそ640TBに相当します。1TBのSSDでは、これは年間約640回のフルドライブ書き込みに相当します。一部の消費者向けSSDは600TBW程度の定格であるため、これは1年未満でほぼ全ドライブの保証された書き込み耐久性を使い果たす可能性があります。 証拠 logs_2.sqliteの現在の保持行数: metric value retained rows 681,774 estimated retained log content 1,035.6 MiB レベル分布: level estimated MiB byte % TRACE 732.5 70.7% INFO 266.5 25.7% DEBUG 30.6 3.0% WARN 5.9 0.6% 最大のターゲット+レベルの組み合わせ: target level estimated MiB codex_api::endpoint::responses_websocket TRACE 527.4 codex_otel.log_only INFO 141.2 codex_otel.trace_safe INFO 121.2 log TRACE 97.4 codex_client::transport TRACE 60.1 codex_core::stream_events_utils DEBUG 27.5 codex_api::sse::responses TRACE 19.1 上位のソースは、ほとんどがグローバルなTRACEログ、ミラーリングされたテレメトリーログ、および生のwebsocket/SSEペイロードロギングです。TRACEのみで保持バイトの約70.7%を占めています。codex_otel.log_only + codex_otel.trace_safeでさらに25.3%が追加されます。これらのカテゴリをフィルタリングすることで、フィードバックログを完全に無効にすることなく、このサンプルで保持されているログバイトの約96%を削除できるはずです。 最も頻繁なTRACEソースからのサニタイズされた例: target=log これらは高頻度で保持されるサンプルです。生のwebsocket/SSEペイロードボディは、プライベートな会話内容を含む可能性があるため、意図的に含まれていません。 128,764x TRACE log: inotify event: ... mask: OPEN, name: Some("ld.so.cache") 37,982x TRACE log: inotify event: ... mask: OPEN, name: Some("locale.alias") 23,843x TRACE log: inotify event: ... mask: OPEN, name: Some("passwd") 3,639x TRACE log: <tokio-tungstenite checkout>/src/compat.rs:131 AllowStd.with_context 3,505x TRACE log: <tokio-tungstenite checkout>/src/lib.rs:245 WebSocketStream.with_context 3,362x TRACE log: <tokio-tungstenite checkout>/src/compat.rs:154 Read.read 3,356x TRACE log: <tokio-tungstenite checkout>/src/compat.rs:157 Read.with_context read -> poll_read 3,230x TRACE log: <tokio-tungstenite checkout>/src/lib.rs:294 Stream.poll_next 3,227x TRACE log: <tokio-tungstenite checkout>/src/lib.rs:304 Stream.with_context poll_next -> read() 3,213x TRACE log: inotify event: ... mask: OPEN, name: Some("nsswitch.conf") 2,001x TRACE log: WouldBlock 1,217x TRACE log: Masked: false 1,169x TRACE log: Opcode: Data(Text) 1,169x TRACE log: First: 11000001 頻繁なINFOソースからのサニタイズされた例 支配的なINFOソースは、ほとんどが繰り返されるOpenTelemetryミラーイベントです。IDは編集されています。 843x INFO codex_client::custom_ca: using system root certificates because no CA override environment variable was selected ... 334x INFO codex_otel.trace_safe: session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id=<redacted> codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...} 333x INFO codex_otel.log_only: session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input" submission.id=<redacted> codex.op="user_input"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...} 332x INFO codex_otel.log_only: session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id=<redacted> codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...} 332x INFO codex_otel.trace_safe: session_loop{thread_id=<redacted>}:submission_dispatch{otel.name="op.dispatch.user_input_with_turn_context" submission.id=<redacted> codex.op="user_input_with_turn_context"}:turn{otel.name="session_task.turn" thread.id=<redacted> ...} 書き込み増幅 保持されたDBサイズは実際の書き込み量を隠蔽しています。15秒のサンプルでは: metric before after retained rows 681,774 681,774 max row id 5,003,347,015 5,003,383,226 15秒間に約36,211行が挿入されましたが、保持行数は横ばいでした。これは、継続的な挿入と削除による書き込み増幅を示唆しています。行が挿入され、インデックスが作成され、WALに書き込まれ、その後削除されています。 考えられる原因 SQLiteフィードバックログシンクは、グローバルなTRACEデフォルトでインストールされています: Targets::new().with_default(Level::TRACE) これにより、依存関係/内部ログや大規模な生プロトコルペイロードを含むすべてのターゲットがデフォルトでTRACEレベルで永続化されます。 提案された修正 フィードバックログは有効にしたまま、デフォルトで永続化するものを絞り込みます: SQLiteフィードバックログシンクにグローバルなTRACEを使用しない。 低価値の依存関係ノイズ、特にtarget=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を無視するため、ストリーミング中にSQLite WALへの過剰な書き込みが発生する #17320 Codex Desktopは通常のアクティブ使用中にlogs_2.sqlite / WALが急速に増加する #24275 app-server: フィードバックログsqlite (logs_N.sqlite) が無制限に増加する — 約0.75 GB/日、保持/ローテーションなし #26374 logs_2.sqlite-wal は無限に増加し、古い/一時停止されたCodex TUIプロセスが削除されたWALを開いたままにするため、削除後も割り当てられたままになる #22444 アイドル状態のcodexプロセスからの大量のI/Oアクティビティ #20563 Codex拡張機能/CLI使用時のWindows WSL2での深刻なディスクI/O / 100%ディスクアクティブ時間 #27020 goals_1.sqliteの書き込み増幅: 4 KBデータベースで約11 MB/秒の持続的な書き込み (生涯11 GB) #27911 app-server/rendererのメモリとTRACEログのチャーンにより、Codex Desktopは長いアクティブスレッドで利用不能になる #21134 app-server: sqliteからトレースレベルでフィードバックログを生成/ログ出力する #12969 リアクションは現在利用できません メタデータ メタデータ 担当者 誰も割り当てられていません ラベル CLI Codex CLIに関連するイシュー Codex CLIに関連するイシュー バグ 何かうまくいかない 何かうまくいかない パフォーマンス タイプ タイプなし フィールド タイプのないイシューに対してはフィールドが設定されていません。 プロジェクト プロジェクトなし マイルストーン マイルストーンなし 関係 まだありません 開発 ブランチもプルリクエストもありません イシューアクション