Codex is EATING my Mac's disk space

TEXT START: Codex Desktop is continuously adding paired .dmp and _sidecar.json files under:

The Dissection

This is a crash-loop incident report disguised as a storage complaint. The supplied evidence establishes an active, unbounded feedback loop:

• Crashpad pending files grow at machine speed, reaching at least 137 GiB.
• browser_crashpad_handler appears to crash on its own fatal mach_port_request_notification failure.
• Each handler failure generates another dump, turning the diagnostic subsystem into the main source of damage.
• Deleting the queue recovers space, but new files immediately return.
• Reinstalling and disabling browser backends do not stop the growth.
• Making the Crashpad database unwritable stops disk growth only by suppressing reporting. That is containment, not repair.

The report is strongest when it separates foreground usability from system health. The app can remain functional while a background process quietly liquidates the host's finite storage. The later comments mix versions, macOS releases, related cache behavior, and unverified claims, so they do not establish one universal root cause. The Crashpad handler loop is the best-supported proximate mechanism; the initiating lifecycle or compatibility defect remains unproven.

The Core Fallacy

The central fallacy exposed here is equating “the app still works” with “the system is healthy.” That is false. An automated background process can satisfy foreground requests while consuming the machine beneath them.

Relative to Discontinuity Thesis mechanics, this is a small but clean example of automation without a hard resource boundary: a minor fault becomes high-rate damage because no effective quota, circuit breaker, rotation policy, or supervisor intervenes. The report also risks treating the handler's fatal error as the complete root cause. It identifies the weapon, not necessarily the hand that pulled the trigger.

Hidden Assumptions

• Crash reports will be uploaded, processed, rotated, or bounded automatically.
• A crash-reporting component cannot become the crashing component.
• App usability implies low incident severity.
• Local disk is an acceptable unpriced buffer for software failure.
• Reinstalling the application resets all relevant helper state and databases.
• Different versions and macOS releases in the comments share one cause.
• A read-only or immutable Crashpad directory is a safe long-term workaround.
• The later claim that newer macOS versions fix the problem is evidence of resolution; the supplied text does not prove that.
• The comments blaming “vibe coding” are causal analysis. They are rhetoric, not evidence.

Social Function

Primary classification: partial truth with transition-management function.

The report converts an invisible software failure into measurable damage: file counts, growth rates, process ancestry, crash signatures, and a reproducible containment result. It forces maintainers to confront storage exhaustion as a product-safety failure rather than dismissing it as an ordinary crash.

It is not copium or a lullaby. The “vibe coding” comments are ideological scapegoating layered onto a real defect. They may express justified anger, but they do not explain the mechanism.

The Verdict

This is a concrete reliability failure in which the diagnostic machinery becomes a self-feeding parasite. “Functional” is a misleading label when the application is consuming tens or hundreds of gigabytes while remaining open.

The report does not prove that Codex as a product is obsolete, nor does it prove that AI-generated development caused the defect. It does show the characteristic danger of automated systems without enforced limits: machine-speed failure, human-scale oversight, and the user left holding the carcass. Until bounded queues, crash-loop detection, circuit breakers, and guaranteed cleanup exist, the application is operational only in the narrowest and most deceptive sense.