Codex Desktop Crashpad バグ（Issue #25921）：無制限の保留ダンプがmacOSディスクを埋め尽くす

OpenAIのmacOS向けCodex Desktopアプリは、サイズ上限、有効期限、プルーニングなしに、ローカルの pending ディレクトリにCrashpadクラッシュダンプを継続的に生成します。そのため、アプリ自体は使用可能なまま、フォルダは無制限に成長します。GitHubのIssue openai/codex#25921 は、ユーザーJolg42が2026年6月2日に開設したもので、1日で4.9GB、54,504ファイルという最初の報告を記録しています。その後の4ヶ月間のフォローアップコメントでは、59GB、61GB、100GB、137GB、174GB、そして1台のマシンで2つのCrashpadパスにまたがる合計約323GBが報告されています。

このIssueには app、bug、performance というラベルが付けられており、ソース取得時点ではまだオープンでした。核心となる欠陥には、分離可能な2つの部分があります。影響を受けるmacOSバージョンでクラッシュして再スポーンを繰り返すCrashpadハンドラと、それらのクラッシュが書き込まれるディレクトリに対する保持制限が完全にないことです。

バグの実際の内容

Codex Desktopには、Chromium/Electronの browser_crashpad_handler ヘルパーが同梱されています。影響を受けるマシンでは、このハンドラが起動時に失敗し、自身のミニダンプを書き込んでから再起動され、同じチェックで再び失敗します。各イテレーションで、Crashpadの pending キューにペアの .dmp ファイルと _sidecar.json メタデータファイルが生成されます。

ユーザーに表示される症状は、Codexアプリのクラッシュではありません。アプリは機能し続けます（ユーザーは同じセッションから操作したり、ファイルシステムを調べたりできます）が、その間、ディスク使用量はバックグラウンドで静かに増加します。アプリ内で警告が表示されることはありません。

バージョン別の報告されたディスク使用量

成長の規模は、マシンやループが検出されずに実行された時間によって大きく異なりました。

報告者 日付 アプリバージョン 報告されたサイズ ファイル数
Jolg42（作成者） 2026年6月2日 26.527.60818 1日で4.9GB 54,504
mxggle 2026年6月7日 — 59GB 65,535ファイルの上限に達した
dionylon 2026年6月9日 26.602.71036 58.89GiB 738,864
guojianlan 2026年6月18日 26.611.62324 137.32GiB 1,786,086
libairi 2026年7月21日 26.715.70719 約33.4GiB —
austinhutchison 2026年8月15日 26.803.61601 約100GB 約100万
dewalt-1 2026年9月2日 26.818.41509 174.6GB 約108万ダンプ、200万以上のファイル
ashtonsix 2026年10月5日 26.930.21537 114.22GB 1,212,428
ahmedkhan25 2026年10月17日 26.1007.71326 2つのパスで約323GB 約404万

最初の報告では、27,252個の .dmp ファイルと27,252個の _sidecar.json ファイル（正確に1:1のペア）が測定され、合計4.9GBでした。作成者が内容を削除した後、ディレクトリは6.4MBと70ファイルに減少しましたが、新しいペアのファイルがすぐに出現し、古いバックログではなくアクティブな生成が確認されました。

正確なハンドラの失敗

複数の報告者が、最新の .dmp ファイルから同じ致命的なメッセージを抽出しました。これは、Codexアプリやレンダラーではなく、Crashpad自身の例外ハンドラサーバーからのものです。

[FATAL:third_party/crashpad/crashpad/handler/mac/exception_handler_server.cc:76]
Check failed: kr == KERN_SUCCESS.
mach_port_request_notification: (os/kern) invalid capability (20)

ダンプには、クラッシュしたプロセスがハンドラ自身であることを識別する注釈が含まれています。

executable_path=/Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/152.0.7977.64/Helpers/browser_crashpad_handler
--monitor-self-annotation=ptype=crashpad-handler
ptype=crashpad-handler

macOS自身の診断ログもこれを裏付けています。報告者は、~/Library/Logs/DiagnosticReports の下に、procName: browser_crashpad_handler、exception: EXC_BREAKPOINT / SIGTRAP、coalitionName: com.openai.codex を持つ繰り返しの .ips エントリを発見しました。

ループが終了しない理由

ユーザーReymondAkpanyaは、2026年9月21日のコメントで、自己持続サイクルの最も明確な説明を提供しました。ハンドラは --monitor-self-annotation 付きで起動されるため、自身を監視します。シーケンスは次のとおりです。

  1. ハンドラが mach_port_request_notification を呼び出し、KERN_INVALID_CAPABILITY (20) を受け取ります。
  2. exception_handler_server.cc:76 の CHECK に達して終了します。
  3. セルフモニターがハンドラのミニダンプを書き込みます。
  4. ハンドラが再起動され、同じチェックで失敗し、ステップ2に戻ります。

基本ケースのないループであり、そのため成長はアプリのアクティビティと相関するのではなく、完全に線形です。

その報告からの測定レート：正確に1秒間に1ダンプ、各181,552バイト、さらに24バイトの _sidecar.json — 1時間あたり約3,600ダンプ、1時間あたり約0.6GB、アプリ実行中は1日あたり約15GB。その場合、キューは240,966ファイルと21GBに達し、228GBのディスクを0バイトの空き容量まで消費しました。completed/ ディレクトリは240,966のレポートすべてで空であり、キューを排出するものは何もないことを意味します。

上流の原因はCodex固有ではない

mach_port_request_notification / KERN_INVALID_CAPABILITY の失敗は、macOS上のCrashpadのMach IPC問題であり、Codexに固有のものではありません。macOS Tahoe 26.3.1での同じエラーは、Claude Desktop（anthropics/claude-code#37230）やVS Code（microsoft/vscode#282433）を含む他のChromium/Electronアプリケーションに対して報告されています。

この区別は、バグを評価する人にとって重要です。上流の CHECK の失敗は環境によるものです。無制限のディスク消費はそうではありません — ハンドラの起動失敗が繰り返し発生する場合、セルフモニターがハンドラ自身の致命的な CHECK を報告可能なクラッシュとして扱うため、同じ暴走が発生します。ReymondAkpanyaが言うように、トリガーは上流にありますが、増幅はそうではありません。

保持バグはクラッシュループとは独立している

ユーザーdewalt-1は、これらが2つの別個の欠陥であるという最も強い主張をしました。2026年9月2日、彼らは ~/Library/Application Support/Codex/Crashpad/pending に174.6GBを報告し、Application Support/Codex の他のすべてを合わせた171MBと比較しました — ディレクトリの99.9%です。ダンプは均一な約161KBのペアで、約108万ダンプと200万以上のファイルでした。

重要なのは、そのマシンはタイトなループではなかったことです：pending/ への最後の書き込みは16時間前で、アプリはそれ以降追加せずに実行されていました。Crashpad/ ディレクトリは2026-04-05に作成されており、5ヶ月間で平均1日あたり約1.1GBであり、1日あたり5〜17GBではありません。

ダンプを生成するものが何であれ、それらをプルーニングするものはありません。保持バグは特定のクラッシュループから分離可能に見えます：クラッシュレートが低くても、5ヶ月で175GBに達します。pending/ のサイズまたは年齢上限は、クラッシャーを修正することとは独立して、被害を制限します。

ユーザーjakehopは2026年8月9日に、Crashpadにはこの統合では実装されていないプルーナーが同梱されていると指摘しました：「他のElectronアプリでもこの動作を見たことがあります。ハンドラは配線されていますが、プルーナーは配線されておらず、テレメトリがオフまたはブロックされている場合、これらのログはpendingに溜まり続けます。」

影響を受けるパスとバージョン

レポートには2つのCrashpadデータベースパスが登場し、同じマシンで両方が影響を受ける可能性があります。

  • ~/Library/Application Support/com.openai.codex/web/Crashpad/pending — 初期のCodex Desktopビルドで使用されたレガシーパス。
  • ~/Library/Application Support/Codex/Crashpad/pending — 統合されたChatGPT/Codexデスクトップアプリで使用される新しいパス。

ahmedkhan25は2026年10月17日に両方を同時に測定しました：レガシーパスに180GB / 2,251,765ファイル、新しいパスに143GB / 1,785,095ファイル、合計約323GBと約404万ファイル — 926GBディスクの約35%。彼らが発見するまでに空き容量は1.4GBにまで減少していました。

報告されたアプリバージョンは、26.527.60818（6月）から 26.1007.71326 ビルド 20398（10月）までで、Chromiumフレームワークバージョンは 148.0.7778.179 から 155.0.8059.40 までです。レポート内の影響を受けるmacOSバージョンは、15.xと26.0〜26.3に集中しています。

バージョンとプラットフォームのシグナル

コントリビューターのdnakovは2026年6月14日にコメントしました：「これは後のmacOSバージョンで修正されていると思います。少なくとも26.5では。」ユーザーnathanvyは2026年10月18日に、macOS 26.6.2でcodex v26.1013.40934ビルド20770を実行して影響を受けていないと報告しました。

このパターン — 15.xと26.0〜26.3で影響、26.5+で影響なし — は、Mach IPCの失敗がカーネルバージョンに依存していることと一致しています。ただし、スレッドには新しいビルドと新しいパスに関するレポートも含まれており、libairiはアプリのビルドをロールバックするだけでは役に立たないことを発見しました：ビルド5538（26.715.31251）とビルド5650はどちらもChromium 150.0.7871.124 を使用し、同じMach-O UUIDを共有し、署名されていないコード領域のSHA-256ハッシュが同一です。

ユーザーによって報告された回避策

1. 保留レポートを削除する

最も簡単な封じ込めは、pending ディレクトリ内のファイルを直接削除することです。作成者自身のcronエントリ（2026年6月20日投稿）：

*/15 * * * * /usr/bin/find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f -delete >/dev/null 2>&1 || true

crontab -e で設定し、crontab -l で確認します。これは pending ディレクトリ内のファイルのみを直接削除します。

2. pendingディレクトリを読み取り専用にする

複数のユーザーが、ディレクトリを空にした後、書き込み権限を削除することで成長を止めました。ReymondAkpanyaのバージョン：

P=~/Library/"Application Support"/Codex/Crashpad/pending
find "$P" -type f -delete
chmod 500 "$P"

彼らは、成長が止まり、new/、completed/、attachments/ に何もこぼれないことを確認しました — Crashpad ディレクトリ全体が20Kのままです。chmod 700 で元に戻します。

dionylonは、データベース全体に対してより強力なバリアントを使用し、pending、new、completed、attachments のサブディレクトリを再作成した後、chmod -R 555 と chflags -R uchg を組み合わせました。これにより、観測されたウィンドウではpendingがゼロで停止しました。彼らは、macOSが sudo でもハンドラバイナリ自体の変更を許可しないこと（Operation not permitted）に言及しました。

3. 削除する代わりにファイルをゴミ箱に移動する

ユーザーliuminsheng3は、アプリデータディレクトリ全体を削除するのではなく、Crashpadレポートバケットのみをゴミ箱に移動し、最初にハンドラを停止することを推奨しました：

osascript -e 'quit app "Codex"' 2>/dev/null || true
pkill -f "browser_crashpad_handler.*codex.*/Crashpad" 2>/dev/null || true

for crash in \
  "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" \
  "$HOME/Library/Application Support/Codex/Crashpad"; do
  [ -d "$crash" ] || continue
  mkdir -p "$HOME/.Trash/Codex-Crashpad"
  for bucket in pending new completed attachments; do
    [ -d "$crash/$bucket" ] || continue
    find "$crash/$bucket" -mindepth 1 -maxdepth 1 -exec mv {} "$HOME/.Trash/Codex-Crashpad/" \;
  done
done

これは大規模な場合に重要です：ahmedkhan25は、数百万の小さなファイルの削除は遅い一方で、フォルダの名前変更は即座であると報告しました。its-tahirも同じアドバイスをしました — 「Crashpadフォルダをゴミ箱に移動してください。数百万のファイルがあっても即座ですが、400万ファイルでの rm は遅いです。」

4. LaunchAgentによる制限付き保持

ashtonsixは、5分ごとに実行され、24時間より古いレポートを期限切れにし、各pending/completedキューを64レポートグループと256MiBに制限するLaunchAgentをインストールしました。一致するUUIDのダンプ/サイドカーファイルをグループ化し、新しい書き込みに2分の猶予期間を与え、不明なファイル、シンボリックリンク、検査中に変更されるファイルをスキップします。彼らはこれを、データベースを書き込み不可にすることなく、保持された診断ストレージを制限するものとして明確に位置付けました — クラッシュするヘルパーの修復としてではありません。

効果がなかった回避策

libairiは統合アプリでいくつかのアプローチをテストし、すべて効果がなかったと報告しました：

  • --disable-breakpad で起動しても、新しいCrashpadレポートは防止されませんでした。
  • ハンドラの実行を拒否すると、保留ダンプは停止しましたが、macOSの「ChatGPTが予期せず終了しました」というレポートとポップアップが繰り返し発生しました。
  • Crashpad/pending のみを定期的に削除するとディスク使用量は抑えられますが、ハンドラのクラッシュループは修正されません。

dionylonはまた、完全な再インストールでは修正されず、browser@openai-bundled の無効化、chrome@openai-bundled の無効化、~/.codex/config.toml での BROWSER_USE_AVAILABLE_BACKENDS = "" の設定が、再起動後のダンプ成長を止めなかったと報告しました。

読み取り専用の回避策に関する安全上の注意

ユーザーliuminsheng3は、Crashpad/pending を読み取り専用にすることは、デフォルトのクリーンアップパスではなく、緊急ブレーキとして扱うべきだと警告しました。アクティブなダンプループは停止しますが、Codexがクラッシュレポートを書き込むのを防ぎ、メンテナーが必要とするシグナルを隠す可能性があります。彼らは、スコープを狭く保ち、~/Library/Application Support/Codex、~/Library/Application Support/com.openai.codex、および一時的な com.openai.codex.code_sign_clone ディレクトリで永続的な読み取り専用状態を避けることを推奨しました。

彼らが提案した順序：Codexを終了します。Crashpadレポートバケットのみをゴミ箱に移動します。再起動して pending が再び成長するかどうかを確認します。アクティブに再充填されている場合にのみ読み取り専用の回避策を適用します。アプリまたはバージョンの問題が修正された後、読み取り専用ビットを元に戻します。

影響を受けているかどうかを確認する方法

its-tahirはスレッドに簡潔なトリアージサマリーを投稿しました。両方のCrashpadパスのサイズを確認します：

du -sh "$HOME/Library/Application Support/Codex/Crashpad" \
       "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" 2>/dev/null

ダンプが今まさに書き込まれているかどうかを確認します — 最後の1分間に約60個の .dmp ファイルがある場合、ループが実行されています：

find "$HOME/Library/Application Support/Codex/Crashpad/pending" \
  -maxdepth 1 -name '*.dmp' -mmin -1 | wc -l

次に、アプリを終了し、pgrep -fl browser_crashpad_handler で残りのハンドラを確認し、Crashpadフォルダをゴミ箱に移動します。

ダンプを公開共有すべきでない理由

証拠を添付したすべての報告者は、生の .dmp ファイルを差し控えました。元の作成者は次のように述べています：「ミニダンプにはメモリ、ローカルパス、またはプライベートデータが含まれる可能性があるため、公開で添付しません。OpenAIのメンテナーが安全なアップロードパスを提供すれば、最新の .dmp をプライベートで共有できます。」後の複数のコメンテーターも同じ注意を繰り返し、ダンプにはメモリ、ローカルパス、プロンプト、またはプロジェクト状態が含まれる可能性があると指摘しました。メタデータ — カウント、サイズ、最も古いタイムスタンプと新しいタイムスタンプ、アプリバージョン、どのパスがまだ成長しているか — は公開トリアージに十分であると考えられました。

Hacker Newsでのコミュニティの反応

Hacker Newsのディスカッション（156ポイント、73コメント）は、技術的なメカニズムよりもパターンに焦点を当てていました。複数のコメンテーターは、これがSSDの摩耗に影響を与える最初のCodexバグではないと指摘しました。1人は以前のCodexの無限ロギング問題に言及しました。

「これはSSDに大きな耐久性の影響を与える可能性のある2番目のCodexバグですが、無限ロギングを行った最初のものほど深刻ではありません。」

他の人々は、Crashpadではなく隣接する原因によるディスク圧力を報告しました。1人のコメンテーターは、ディスク使用量を、並行する機能間でビルドアーティファクトを複製するgit worktreeと、メモリ制限に達したことによるmacOSの大量スワップに追跡しました。別の人は、Codex worktreeに残された数千のスクリーンショットとアーティファクト、およびWindows VMで生成された90GBの不要な検証テストを報告しました。そのコメンテーターは次のように付け加えました：「これは間違いなくCodexのことであり、Claude CodeやAntigravityでこれが起こるのを見たことはありません。」

別のコメンテーターは、~/.bun/install/cache/@openai に、それぞれ約300MBの11個の重複する codex と codex-code-mode-host バイナリを発見しました。別の人は、.staging/marketplace ディレクトリに14GBの小さなファイルを報告しました。

いくつかのコメントは、最初の報告から修正までの4ヶ月のギャップを鋭く批判しました。1人は、Crashpad自身のプルーナーが存在するが、この統合では配線されていないと指摘しました。別の人は、ユーザーがコア製品のバグを修正してもらうのではなく、回避策を求められていると観察しました。

スレッドからの実用的な提案には、エージェントハーネスをDockerコンテナに追いやること、DaisyDiskなどのディスク可視化ツールを使用して成長を見つけること、使用済みディスク容量を表示するChatGPTアプリ設定のストレージセクションを確認することが含まれていました。

修正が対処する必要があるもの

ReymondAkpanyaは、それぞれが最悪の結果を防いだであろう2つの独立した緩和策を提案しました：

  1. セルフモニターがハンドラ自身の起動 CHECK 失敗を報告するのを止める、またはN回連続して同一のダンプの後にバックオフしてレート制限する。これは上流の原因に関係なくループを断ち切ります。
  2. pending/ をサイズ上限またはTTLで制限する、これにより、静かに失敗するアップロードパスがディスクを満たすことができなくなります。

どちらか一方があれば、「ディスクが0バイト」からログ行に変わっていたでしょう。

ahmedkhan25は同じ精神で3つの要望を追加しました：自動プルーニングを備えた Crashpad/pending のサイズまたはカウント上限。ハンドラのクラッシュループの修正。Codex自身のデータが数GBを超えたときのアプリ内警告。

ステータス

このIssueは、ソース取得時点で app、bug、performance のラベルが付いたままオープンでした。スレッド内の最新のレポート（2026年10月）は、アプリバージョン 26.1007.71326 ビルド 20398 までと、両方のCrashpadパスでのバグを説明しています。コントリビューターのコメントは、後のmacOSバージョン（26.5以上）は影響を受けないことを示唆し、macOS 26.6.2の1人のユーザーは影響がないと報告しました — しかし、スレッドには新しいビルドのレポートと、ハンドラバイナリが隣接するビルド間で変更されていないという証拠も含まれています。公式の修正または保持制限は、スレッドで確認されていません。

Sources