Codex Desktop на macOS забивает диск дампами Crashpad: 4,9 ГБ за день

В репозитории openai/codex на GitHub заведено обращение №25921 о том, что десктопное приложение Codex Desktop для macOS непрерывно создаёт парные файлы .dmp и _sidecar.json в папке ~/Library/Application Support/com.openai.codex/web/Crashpad/pending. У автора отчёта (пользователь Jolg42) за один день эта папка выросла до 4,9 ГБ и 54 504 файлов: 27 252 файла .dmp и столько же _sidecar.json. Пока он разбирался, число файлов продолжало расти: 53 444, затем 54 064, затем 54 504. По его словам, это активная генерация дампов, а не остатки с прошлых сбоев. Замеры относились к версии приложения 26.527.60818 на macOS 26.3.1 (arm64).

Важная деталь: приложение при этом остаётся рабочим. Автор пользовался им, изучал файловую систему и писал на GitHub из той же сессии, то есть проблема не в падении или невозможности запуска, а в неограниченном росте занятого места на диске. Он также увидел два процесса browser_crashpad_handler с PPID=1, запущенных с 30 мая 2026 года и работающих с одной и той же базой Crashpad. По его оценке, похоже, что Crashpad или отслеживаемый им вспомогательный процесс раз за разом создаёт ожидающие дампы без ограничения, очистки после загрузки или обработки и без ротации. Сами минидампы автор публично не выложил, так как они могут содержать память, локальные пути и личные данные; готов передать свежий дамп приватно, если разработчики дадут безопасный способ загрузки. Среди возможно связанных обращений он указал отчёты о зависшем вспомогательном процессе Crashpad после обновления (№25259), об осиротевших процессах и зависаниях интерфейса (№11090) и о проблемах запуска на macOS Tahoe (№10627).

Позже автор очистил папку: после удаления осталось 6,4 МБ и 70 файлов (35 .dmp и 35 _sidecar.json), но новые пары файлов появились сразу. Это он считает подтверждением того, что генерация продолжается.

В комментариях к обращению появились похожие и более тяжёлые случаи. Один пользователь на более новой сборке 26.602.71036 сообщил о папке около 61 ГБ: 738 864 файла (369 431 .dmp и 369 433 _sidecar.json), 63 233 668 274 байт (58,89 ГиБ), из них 98 218 файлов за последние 24 часа и 573 480 за 7 дней; самый старый файл от 1 июня 2026, самый новый от 9 июня. После очистки, переустановки и перезапуска папка продолжала расти примерно на один отчёт о сбое в секунду. В самых свежих .dmp он нашёл фатальное сообщение от самого browser_crashpad_handler: проверка kr == KERN_SUCCESS не прошла в exception_handler_server.cc, ошибка mach_port_request_notification, invalid capability (20). Системные журналы тоже показывают повторные падения этого процесса (EXC_BREAKPOINT / SIGTRAP). Отсюда вывод комментатора: в его случае обработчик, похоже, падает и перезапускается в цикле, записывая дампы о самом себе. Он отмечает, что до этого у него перестал работать встроенный браузер (Browser Use), и допускает, что это может быть, а может и не быть причиной.

Отключение плагинов browser@openai-bundled и chrome@openai-bundled и пустое значение BROWSER_USE_AVAILABLE_BACKENDS в ~/.codex/config.toml рост не остановили. Помог временный обход: так как macOS не позволила изменить сам обработчик даже через sudo (Operation not permitted), комментатор очистил папку Crashpad и сделал её доступной только для чтения и неизменяемой (chmod 555 и chflags uchg). После этого pending оставалась пустой весь период наблюдения. Он подчёркивает, что это лишь способ остановить рост диска, а не исправление, ведь так Codex фактически не может записывать отчёты Crashpad.

Другие участники обсуждения пишут, что столкнулись с тем же: один очистил 22 ГБ за день, другой видит проблему на версии 26.601.10930. Ещё один комментатор указал на непрерывное создание отчётов в системной папке /System/Library/Caches/com.apple.coresymbolicationd/data и приложил скрипт для проверки. Кто-то считает, что в более поздних версиях проблема исправлена, «по крайней мере в 26.5». Заголовок обращения 9 июня изменили на «растёт без какого-либо предела: минимум +5 ГБ в день». Часть комментаторов выражает раздражение качеством приложения.

Ключевые факты

• У автора отчёта на GitHub папка Crashpad/pending в Codex Desktop для macOS выросла до 4,9 ГБ и 54 504 файлов за один день (27 252 файла .dmp и столько же _sidecar.json), версия приложения 26.527.60818.
• Приложение остаётся рабочим, проблема в неограниченном росте занятого места: после ручной очистки (6,4 МБ, 70 файлов) новые пары файлов появились сразу.
• Другой комментатор на сборке 26.602.71036 насчитал около 61 ГБ и 738 864 файла; рост продолжался примерно на один отчёт в секунду даже после переустановки.
• По его данным, в свежих дампах фатальная ошибка самого browser_crashpad_handler (mach_port_request_notification, invalid capability), то есть обработчик, похоже, падает в цикле.
• Временный обход: сделать папку Crashpad только для чтения и неизменяемой (рост останавливается, но Codex больше не пишет отчёты Crashpad). Причина и исправление от разработчиков в видимом тексте не названы.

Почему это важно

Десктопный клиент для работы с кодом молча забирает у пользователя десятки гигабайт, при этом выглядит полностью исправным: приложение не падает и запускается. Заметить проблему можно только по заполняющемуся диску. В обращении сообщается о 4,9 ГБ за день у автора и около 61 ГБ у другого пользователя (за период с 1 по 9 июня 2026 по датам файлов). Заголовок обращения со временем изменили на формулировку «минимум +5 ГБ в день».

Кому это важно

Прежде всего пользователям Codex Desktop на macOS: в обращении идёт речь именно об этой платформе, о Windows и Linux в видимом тексте ничего не сказано. Особенно тем, у кого на маке мало свободного места и кто не следит за содержимым папки ~/Library/Application Support. Также тем, кто администрирует парки маков с этим приложением, и разработчикам, которые используют Chromium/Electron с Crashpad и могут столкнуться с похожей картиной.

Как это применить

Проверить, затронуты ли вы, можно по размеру папки: du -sh "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" и по числу файлов в ней. По данным автора отчёта, удаление содержимого pending возвращает место, но если генерация активна, папка начнёт расти снова. Один из комментаторов описал обход: очистить папку Crashpad и сделать её read-only и неизменяемой через chmod 555 и chflags uchg; у него рост остановился, но это не исправление, потому что приложение перестаёт записывать отчёты Crashpad. Отключение плагинов браузера и BROWSER_USE_AVAILABLE_BACKENDS в config.toml ему не помогло. Один из участников обсуждения считает, что в более поздних версиях проблема решена, но конкретной исправленной версии приложения в видимом тексте нет.

Можно ли доверять

Это пользовательский отчёт об ошибке на GitHub, а не заявление OpenAI. Цифры взяты из собственных замеров автора и комментаторов, их подтверждение независимыми измерениями в видимом тексте отсутствует. Ответа или признания проблемы от разработчиков OpenAI в видимом тексте нет, причина не подтверждена: авторы только строят предположения («похоже», «может быть, а может и нет»). Количество затронутых пользователей не указано. Страница обращения в доступном виде обрезана, а конец скрипта одного из комментаторов не виден.

Риски и подводные камни

Если генерация дампов активна, папка продолжает расти сколь угодно долго и может заполнить диск, что способно повлиять и на другие программы. Предложенный обход с chflags uchg меняет права на базу Crashpad и лишает приложение возможности записывать отчёты о сбоях; его придётся отменять вручную, а действовать нужно с осторожностью. Сами дампы могут содержать память процесса, локальные пути и личные данные, поэтому автор отчёта не стал выкладывать их публично, и вам не стоит прикладывать их к открытым обращениям. Наконец, версии и симптомы в комментариях различаются (26.527.60818, 26.601.10930, 26.602.71036), поэтому у вас картина может отличаться.

«Похоже, Crashpad или отслеживаемый им вспомогательный процесс раз за разом создаёт ожидающие дампы без ограничения, очистки после загрузки или обработки и без ротации.»

— Jolg42, автор обращения №25921 на GitHub