Codex Desktop frisst Mac-Festplatten: 59 GB Crash-Dumps, ein Bericht pro Sekunde
Codex is EATING my Mac's disk space
Ein GitHub-Issue dokumentiert, wie die Codex Desktop App auf macOS im Hintergrund ungebremst Crashpad-Dumps schreibt. Bei einem Nutzer wuchs das Verzeichnis auf 59 GB mit über 738.000 Dateien, bei einem anderen um mindestens 5 GB pro Tag. Ursache ist offenbar ein browser_crashpad_handler, der in einer Schleife abstürzt und sich selbst neue Dumps erzeugt – selbst nach Neuinstallation. Ein Nutzer stoppte das Wachstum nur, indem er die Crashpad-Datenbank schreibgeschützt und unveränderlich machte.
Sogar als wir das Dateisystem-Limit von 65535 erreicht hatten, versuchte der Hintergrundprozess weiterhin unerbittlich, mehr Dateien zu dumpen.
- glenngillen
Ich hatte auf meinem System starken Platzdruck durch laufende Agenten. Ich habe zwei Hauptursachen entdeckt:
- mein Ansatz, für alle Arbeiten git worktrees zu verwenden. Nicht ganz überraschend, die duplizierten Build-Artefakte in jedem Worktree waren hier der Hauptschuldige. Es gab einige begrenzte Verbesserungen, indem ich einfach effizienter mit der Verwaltung von Builds umging, aber letztlich musste ich die Anzahl der gleichzeitigen Features, an denen ich arbeitete, in ein paar besonders großen Repos begrenzen.
- heimtückischer war die Tatsache, dass ich tatsächlich öfter an Speichergrenzen stieß, als mir bewusst war, und mein Mac dadurch stark swappen musste. Das System war überraschenderweise noch ziemlich leistungsfähig, während das passierte ... bis es das nicht mehr war. Leider ist die einzige „Lösung“, die ich erkennen kann, wenn das passiert, den Rechner neu zu starten. Es gibt keine Möglichkeit, das System dazu zu bringen, einen Teil des Swap-Speichers zurückzugewinnen, sobald er auf die Festplatte geschrieben wurde. Wenn das ein paar Mal am Tag passiert (besonders leicht, wenn man etwas über Nacht laufen lässt), summiert sich das sehr schnell.
- jbellis
Das sieht nach einem Bug aus, aber selbst der normale Happy-Path-Codex erzeugt viele GB an Logs; OpenAI hält das offenbar für in Ordnung, weil es schon seit Monaten so läuft.
Zwei Dinge helfen:
1. Kompression auf Dateisystemebene, ich nutze ZFS, weil Btrfs massive Contention-Probleme bei gleichzeitigen Rust-Builds hat
2. Archivieren Sie Ihre alten Sitzungen mit etwas wie sessionwiki (https://github.com/youdie006/sessionwiki), ich habe das in meine Control Plane integriert (https://github.com/BrokkAi/mjolnir/)
- aaronbrethorst
Ich habe im vergangenen Jahr viel DaisyDisk verwendet: https://daisydiskapp.com
- dingaling911
Ich bin so froh, dass mein erster Schritt darin bestand, diese Harnesses in Docker-Container zu verbannen.
- AgharaShyam
Schauen Sie sich auch den Ordner ~/.bun/install/cache/@openai an.
Aus irgendeinem Grund hatte ich 11 separate codex- und codex-code-mode-host-Binaries darin. Jede wog etwa ~300 MB.