Codex Desktop тихо съел 323 ГБ диска дампами сбоев

Пользователь Codex Desktop на Mac 17 октября добавил в issue на GitHub новые замеры: дампы сбоев Crashpad заняли у него около 323 ГБ, примерно 35% диска на 926 ГБ, и свободными на диске оставались 1,4 ГБ. Issue открыли ещё в конце весны. Тогда речь шла о папке, которая за сутки выросла до 4,9 ГБ.

Замеры сделаны с 15 по 17 октября на ChatGPT.app 26.1007.71326 (build 20398) с Codex Framework на Chromium 155.0.8059.40, macOS 15.7.4, Apple Silicon. Дампы лежат в двух местах. В ~/Library/Application Support/com.openai.codex/web/Crashpad набралось 180 ГБ и 2 251 765 файлов. В ~/Library/Application Support/Codex/Crashpad, почти целиком в подпапке pending, лежат ещё 143 ГБ и 1 785 095 файлов. Всего около 4,04 миллиона файлов.

Приложение ни о чём не предупреждало и всё это время работало. Автор нашёл виновника, только когда прогнал du по ~/Library. По его словам, дампы копятся в фоне тихо и без всякого предела.

Crashpad - это компонент Chromium, который ловит падения процессов и складывает отчёты о них в pending до отправки. Здесь, похоже, падает сам обработчик. В связанном issue описан такой цикл на версии 26.727.51351: browser_crashpad_handler получает SIGTRAP через 2 мс после запуска, launchd перезапускает его, и Crashpad/pending растёт примерно на 17 ГБ в сутки.

В исходном отчёте, на версии 26.527.60818, картина была мельче, но устроена так же. За день в pending появились 54 504 файла: 27 252 файла .dmp и столько же парных _sidecar.json. С 30 мая под PPID=1 работали два процесса browser_crashpad_handler, и оба писали в одну базу Crashpad. Пока автор разбирался, число файлов успело вырасти с 53 444 до 54 504. Сами минидампы он выкладывать не стал, потому что в них может оказаться содержимое памяти, локальные пути или личные данные. 9 июня заголовок issue поменяли: вместо «растёт до ~5 ГБ» теперь написано, что папка растёт без ограничений, минимум на 5 ГБ в сутки.

Есть и другие такие случаи. В другом issue на версии 26.928.21956 папка pending дошла примерно до 168 ГБ, а после очистки снова начала расти при обычной работе в десктопном приложении (не в Codex CLI). Что запускает дампы и какой компонент их пишет, этот автор не знает. Все 15 перечисленных им дампов весят по 175 КБ, к каждому прилагается sidecar на 24 байта, и у всех одна метка времени: 8 октября, 19:40. Поддержка OpenAI посоветовала ему чистить папку при закрытом приложении и обновиться до 26.1002.52244. Воспроизводится ли ошибка на этой версии, пока не подтверждено.

На форуме OpenAI Developer Community пользователь Mac 24 июля писал, что примерно за неделю приложение съело всё свободное место, около 30 ГБ, и что так продолжается как минимум месяц. 7 сентября поддержка ответила в той же теме, что подтвердить исправление, касающееся именно Crashpad, пока не может, и попросила диагностику: версии приложения и macOS, путь к папке и скорость её роста.

Недавно OpenAI пообещала сократить место на диске на 60%, но та переделка касалась того, как приложение хранит своё состояние. Про дампы сбоев там речи не шло.

Автор issue просит три вещи. Первая - лимит на размер или число файлов в Crashpad/pending с автоматической очисткой. Вторая - починить цикл падений обработчика, из-за которого дампы и появляются. Третья - предупреждение в самом приложении, когда его данные занимают больше нескольких гигабайт.

Пока исправления нет, он почистил всё сам: не закрывая приложение, переименовал обе папки Crashpad и удалил переименованные копии. Через несколько минут свободного места было уже больше 50 ГБ вместо 1,4 ГБ, а удаление миллионов мелких файлов всё ещё продолжалось.