Mac の空き容量がなぜか減り続けていて、Codex デスクトップアプリを使っているなら、一つ確認しておきたいフォルダーがあります。OpenAI の Codex リポジトリには 6 月から開いたままの GitHub issue があり、Codex が Crashpad フォルダーにクラッシュダンプを書き続け、数十 GB、場合によっては数百 GB に達したという Mac ユーザーの報告が集まっています。この issue は北京時間 10 月 18 日 1 時 45 分に Hacker News に投稿され、午後には 118 ポイントを集めました。同じ日にもスレッドには新しい報告が寄せられています。
ユーザーが報告していること
issue を立てたのは GitHub ユーザーの Jolg42 氏で、北京時間 6 月 3 日 3 時 9 分のことです。同氏によると、~/Library/Application Support/com.openai.codex/web/Crashpad/pending というフォルダーが 1 日で 4.9 GB、54,504 ファイルに膨らみました。中身はすべて .dmp と _sidecar.json のペアで、調べている間にも数が増え続けたといいます。その間もアプリは普通に使えていたため、問題に気づきにくいのです。Jolg42 氏はその後、ファイルを削除するとフォルダーは数 MB まで減ったものの、すぐに新しいペアが現れ始めたと追記しています。
その後、もっと大きな数字も報告されています。macOS 15.6 のユーザーはフォルダーが約 137 GiB に達したと書き、別のユーザーは 174.6 GB を計測しました。北京時間 10 月 18 日 1 時 37 分には、macOS 15.7.4 のユーザーが、Codex の二つの Crashpad フォルダーが合わせて約 323 GB、926 GB のディスクの約 35% を占め、気づいたときには空き容量が 1.4 GB まで減っていたと報告しています。「アプリからは何の警告もなかった（Nothing in the app warned me）」とのことです。Codex が ChatGPT デスクトップアプリに組み込まれた新しいビルドを使っている何人かのコメント投稿者は、別の場所、~/Library/Application Support/Codex/Crashpad/pending で同じ現象を見つけています。issue には bug、app、performance のラベルが付いており、現在も未解決のままです。
原因とみられるもの
OpenAI は原因を説明していません。ダンプの中身を調べたユーザーによると、これらは Crashpad 自身のハンドラープロセス browser_crashpad_handler のクラッシュレポートで、起動時のチェックに失敗して再起動され、また失敗するたびに新しいダンプを書き出しているといいます。あるコメント投稿者は、ちょうど 1 秒に 1 個のペースでダンプが増えていたと計測しています。pending フォルダーを整理する仕組みが何もないため、クラッシュの頻度が低くても何か月も経てば積み上がる、という指摘もあります。
影響を受ける macOS のバージョン
ここがいちばんはっきりしない点です。北京時間 6 月 15 日 1 時 50 分、GitHub 上で Codex リポジトリのコントリビューターと表示されている dnakov 氏は、「I think this is fixed with later macos versions. at least in 26.5 it is（新しい macOS では直っていると思う。少なくとも 26.5 では直っている）」と書きました。8 月には別のユーザーが、これは macOS 側の既知の修正を指しているのか、Codex の更新も必要なのかと質問しましたが、スレッドでは誰も答えていません。北京時間 10 月 18 日 13 時 18 分には、nathanvy 氏が macOS 26.6.2 で Codex 26.1013.40934 を使っていて影響を受けていないようだと書き、macOS Sequoia からアップデートすれば解決するかもしれないと述べています。スレッドで macOS のバージョンを書いている被害報告は、いずれも macOS 15 か、26.5 より前の macOS 26 でしたが、これは少数の自己申告で、検証されたものではありません。OpenAI は issue に回答しておらず、Codex の更新履歴にもこの問題や修正についての記載はありません。
フォルダーの確認と削除
フォルダーのサイズは、Finder の「移動」メニューから「フォルダへ移動」を選んでパスを貼り付け、pending フォルダーの「情報を見る」で確認できます。ターミナルなら du -sh "$HOME/Library/Application Support/Codex/Crashpad/pending" で同じことがわかり、パスを古い com.openai.codex/web のほうに置き換えればそちらも確認できます。ファイルが数十万個ある場合は、どちらの方法でも時間がかかることがあります。
サイズが大きかった場合は、まず Codex を終了してください。ChatGPT アプリの中で Codex を使っているなら ChatGPT アプリを終了します。そのうえで、pending フォルダーの中のファイルだけを削除します。これは Crashpad が送信待ちのままためているクラッシュレポートで、削除したコメント投稿者は容量を取り戻し、その後もアプリは問題なく動いたと報告しています。Crashpad フォルダーのほかの部分や、アプリ自体のデータが入っている Application Support/Codex フォルダー全体には手を付けないでください。また、ダンプファイルにはプロセスのメモリやローカルのパスなど個人的な情報が含まれる可能性があるとして、コメント投稿者たちは公開の場に上げることを避けています。
フォルダーを空にしても容量が空くだけで、ダンプを生み出している原因が止まるわけではありません。Codex をもう一度開き、しばらくしてからフォルダーを見て、また増えていないか確認するとよいでしょう。pending フォルダーを読み取り専用にして増加を止めたというコメント投稿者もいますが、これは緊急ブレーキのようなもので、本来のクラッシュレポートも書けなくなると注意する声もあります。OpenAI が回答したり修正を出したりした場合は、この記事を更新します。
