Codex Desktop genereert continu Crashpad-dumps die onbeperkt groeien: minimaal +5GB per dag (Issue #25921)

Samenvatting

Op sommige systemen groeit deze directory in één dag tot 4,9 GB met 54.504 bestanden. Het aantal bestanden blijft stijgen tijdens inspectie, wat erop wijst dat er sprake is van actieve generatie van Crashpad-dumps in plaats van oude resten.

Het Codex Desktop-programma blijft functioneel terwijl dit gebeurt; gebruikers kunnen de app gebruiken, het bestandssysteem inspecteren en interactie hebben met GitHub. Het probleem is dus niet dat Codex volledig crasht of niet kan starten, maar dat Crashpad op de achtergrond continu dumps genereert zonder limiet, wat leidt tot onbeperkte groei van het lokale schijfgebruik.

Omgeving

  • Product: Codex Desktop app op macOS
  • Codex app versie: 26.527.60818 (en diverse nieuwere versies zoals 26.602.71036, 26.611.62324, 26.803.61601, 26.825.51511, 26.831.21537, 26.1007.71326)
  • CFBundleVersion: 3437 (variërend per versie)
  • Crashpad/Electron annotatie: prod=Codex_Mac, ver=148.0.7778.179 (variërend per versie)
  • macOS: 26.3.1 (25D771280a), 15.6, 15.7.4
  • Architectuur: arm64

Waargenomen bewijslast

Bestandssysteem en metingen

De Crashpad-pending directory bevindt zich op: ~/Library/Application Support/com.openai.codex/web/Crashpad/pending

Voorbeeldmetingen bij één gebruiker:

  • Totaal volume: 4,9 GB
  • Totaal aantal bestanden: 54.504
  • Aantal .dmp bestanden: 27.252
  • Aantal _sidecar.json bestanden: 27.252

Tijdens een korte inspectie steeg het aantal bestanden van 53.444 naar 54.504, wat bevestigt dat de wachtrij blijft groeien.

Er zijn ook twee browsercrashpadhandler processen waargenomen die draaien onder PPID=1 met de volgende parameters:

/Applications/Codex.app/.../Helpers/browser_crashpad_handler \
--database=~/Library/Application Support/com.openai.codex/web/Crashpad \
--annotation=plat=OS X \
--annotation=prod=Codex_Mac \
--annotation=ver=148.0.7778.179

Impact bij andere gebruikers

Verschillende gebruikers rapporteren extreme schijfbezetting:

  • Eén gebruiker rapporteerde een groei tot 59 GB.
  • Een andere gebruiker zag de directory groeien tot 61 GB (738.864 bestanden), waarbij nieuwe rapporten werden gegenereerd met een snelheid van ongeveer één per seconde.
  • Een derde gebruiker rapporteerde een totale bezetting van 137,32 GiB (1,78 miljoen entries) in de legacy-pad.
  • De meest extreme melding betreft een totaalverlies van 323 GB verspreid over twee paden:
  • ~/Library/Application Support/com.openai.codex/web/Crashpad: 180 GB
  • ~/Library/Application Support/Codex/Crashpad: 143 GB

Technische analyse

De crash-loop

Uit analyse van de nieuwste .dmp bestanden blijkt dat de browsercrashpadhandler zelf crasht. De volgende FATAL melding is teruggevonden:

browser_crashpad_handler
Codex_Mac
crashpad-handler
[0609/103121.674299: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)

De oorzaak van de loop: De handler wordt gestart met de vlag --monitor-self-annotation. Dit betekent dat de handler zichzelf monitort. De sequentie is als volgt:

  1. De handler roept machportrequest_notification aan.
  2. Er treedt een KERNINVALIDCAPABILITY (20) fout op.
  3. De handler crasht door de CHECK op exceptionhandlerserver.cc:76.
  4. De self-monitor schrijft een minidump van de handler.
  5. De handler wordt opnieuw gestart, faalt op dezelfde check, en het proces herhaalt zich.

Dit resulteert in een lineaire groei van bestanden (ongeveer 1 dump per seconde, ±15 GB per dag), onafhankelijk van de activiteit in de applicatie.

Systeemdiagnostiek

Systeemlogs tonen herhaalde crashes van de browsercrashpadhandler met:

  • Exception: EXC_BREAKPOINT / SIGTRAP
  • ProcPath: /Applications/Codex.app/Contents/Frameworks/Codex Framework.framework/Versions/.../Helpers/browsercrashpadhandler

Het is opgemerkt dat dit probleem ook voorkomt in andere Chromium/Electron-applicaties op macOS Tahoe 26.3.1 (bijv. Claude Desktop en VS Code).

Gedrag en verwachtingen

  • Verwacht gedrag: Crashrapporten moeten begrensd zijn, worden geüpload/verwerkt/geroteerd, of niet continu worden gegenereerd terwijl de app bruikbaar blijft.
  • Actueel gedrag: Pending Crashpad-rapporten hopen zich razendsnel op en verbruiken vele gigabytes aan lokale schijfruimte.

Gebruikte commando's voor bewijsvoering

Om de omvang van het probleem vast te stellen, zijn de volgende commando's gebruikt:

du -sh "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending"
find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f | wc -l
find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f | sed 's/.*\.//' | sort | uniq -c | sort -nr
/usr/libexec/PlistBuddy -c 'Print :CFBundleShortVersionString' /Applications/Codex.app/Contents/Info.plist
/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' /Applications/Codex.app/Contents/Info.plist
sw_vers
uname -m
ps ax -o pid,ppid,lstart,command | grep -E 'browser_crashpad_handler|com.openai.codex/web/Crashpad' | grep -v grep

Tijdelijke oplossingen en workarounds

1. Handmatige opschoning en permissies

Het verwijderen van de bestanden herstelt de ruimte, maar de loop start direct opnieuw. Een effectievere methode is om de directory lees-alleen te maken:

crash="$HOME/Library/Application Support/com.openai.codex/web/Crashpad"
pkill -f "browser_crashpad_handler.*com.openai.codex/web/Crashpad" 2>/dev/null || true
chflags -R nouchg "$crash" 2>/dev/null || true
chmod -R u+w "$crash" 2>/dev/null || true
rm -rf "$crash/pending" "$crash/new" "$crash/completed" "$crash/attachments"
mkdir -p "$crash/pending" "$crash/new" "$crash/completed" "$crash/attachments"
chmod -R 555 "$crash"
chflags -R uchg "$crash"

2. Automatische opschoning via Cron

Een andere workaround is het instellen van een cronjob die elke 15 minuten de pending-map leegmaakt:

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

3. Script voor macOS coresymbolicationd cache

Naast de Codex-mappen kunnen crashrapporten zich ophopen in de systeemcache. Gebruikers stellen voor om /System/Library/Caches/com.apple.coresymbolicationd/data te controleren en indien nodig op te schonen met sudo.

Gerelateerde issues

Dit probleem kan verband houden met:

  • #25259: Verouderde Crashpad-helper na update/relaunch.
  • #11090: Wees-processen van Codex en UI-freezes.
  • #10627: Crashpad/macOS startup rapporten.
  • #36982, #39875, #51739, #51361: Diverse meldingen over Crashpad loops en opslaglimieten.

Aanbevelingen voor een definitieve oplossing

  1. Voorkom zelf-rapportage van startup-fouten: De self-monitor zou niet moeten rapporteren wanneer de handler faalt tijdens het opstarten, of er zou een rate-limit moeten zijn na N identieke dumps.
  2. Implementeer opslaglimieten: Voer een maximale grootte of een TTL (Time To Live) in voor de pending/ directory om te voorkomen dat een falende upload-path de volledige schijf vult.
  3. Gebruikerswaarschuwing: Toon een melding in de applicatie wanneer de gegenereerde data een bepaalde drempel (bijv. enkele GB) overschrijdt.