Codex DesktopがMacのディスクを1日5GB以上食い荒らす不具合
Codex is EATING my Mac's disk space
Codex DesktopがCrashpadの保留ダンプを無制限に生成し続け、ユーザーのMacのディスクを圧迫している。報告者Jolg42の環境では1日で4.9GB・54,504ファイルに達し、調査中も増加が止まらなかった。別のユーザーは59GB、さらに別の報告では61GBに達した例もある。アプリ自体は動作しており、browser_crashpad_handlerがクラッシュを繰り返しながら自身のダンプを書き続けるループが原因とみられる。
こちらも同じです。自分の環境では59GBに達しました。すでにファイルシステムの65535の上限に達しているのに、バックグラウンドプロセスはなおも執拗にファイルをダンプし続けています。
HNでの議論
27- jbellis
これはバグのように見えますが、通常の正常系のcodexでも数GBのログを作成します。OpenAIはこれが数ヶ月続いているので問題ないと考えているようです。
助けになる2つのこと:
1. fsレベルの圧縮。私はZFSを使っています。Btrfsは並行Rustビルドで大規模な競合問題があるからです。
2. sessionwiki (https://github.com/youdie006/sessionwiki) のようなもので古いセッションをアーカイブする。私はこれを自分のコントロールプレーン (https://github.com/BrokkAi/mjolnir/) に統合しました。
- glenngillen
エージェントの実行によりシステムのディスクプレッシャーに頻繁に遭遇していました。主な原因を2つ発見しました:
- すべての作業にgit worktreeを使うアプローチ。各worktreeでビルド成果物が重複するのが主な原因で、それほど驚きではありません。ビルドの管理方法をより効率化することで限定的な改善はありましたが、最終的には特に大規模なリポジトリのいくつかで、同時に作業する機能の数を制限する必要がありました。
- より陰湿だったのは、実際には思っていた以上にメモリ制限に達していて、Macが激しくスワップせざるを得なくなっていたことです。その間もシステムは驚くほど性能を維持していました…ある時までは。残念ながら、これが起きたときの唯一の「修正」はマシンを再起動することのようです。一度ディスクに書き込まれたスワップ領域をシステムが再利用する方法はありません。これが1日に数回（特に何かを一晩中実行したままにすると簡単に起こります）スラッシングすると、あっという間に積み上がります。
- AgharaShyam
~/.bun/install/cache/@openai フォルダも調べてみてください。
なぜか私の環境では11個の別々のcodexとcodex-code-mode-hostバイナリがありました。それぞれ約300MBの重さです。