OpenAI Codex Desktop bug fills macOS disks with gigabytes of crash dumps

Codex Desktop is quietly eating disk space

OpenAI's Codex Desktop app for macOS is generating gigabytes of crash reports per day in the background while remaining fully usable, according to a bug report on OpenAI's public codex repository that reached Hacker News's front page. The problem is not that the app crashes — it is that the app's crash-reporting machinery appears to be running wild, with no cap, upload or cleanup keeping the queue bounded.

What users are seeing

The original report, filed on June 2, 2026, describes paired .dmp and _sidecar.json files accumulating under ~/Library/Application Support/com.openai.codex/web/Crashpad/pending. On the reporter's machine, that directory reached 4.9GB and 54,504 files — 27,252 dumps plus 27,252 sidecars — in a single day, and the count kept climbing while the issue was being investigated. Two browser_crashpad_handler processes had been running since May 30, both pointed at the same Crashpad database.

Deleting the pending files reclaimed the space immediately, dropping the directory to 6.4MB, but new dump and sidecar pairs reappeared right away.

Other users reproduced the problem at much larger scale. One commenter reported 59GB accumulated, and said that after hitting what they described as a 65,535-file limit, the background process kept trying to write more. Another user, on a newer build (26.602.71036), measured roughly 61GB (58.89GiB) across 738,864 files, including 98,218 written in the preceding 24 hours. After a cleanup, reinstall and restart, the directory grew at roughly one crash report per second. Affected builds span versions 26.527.60818 and 26.602.71036.

The crash handler appears to be crash-looping

The most useful diagnostic clue is inside the dumps themselves. According to the GitHub issue, the newest .dmp files contain a FATAL message from browser_crashpad_handler — a failed check on "kr == KERN_SUCCESS" after mach_port_request_notification returned an "invalid capability" error. macOS system logs show the same helper process repeatedly dying with EXC_BREAKPOINT / SIGTRAP exceptions.

In other words, the component responsible for capturing crashes is crashing in a loop and dutifully writing a crash report about itself on every iteration. One reporter also noted that the in-app browser feature had become unavailable shortly before the dump storm began, suggesting the browser, Chromium and Crashpad path is involved, though that connection is not confirmed.

Workarounds

Neither a reinstall nor disabling the bundled browser backends stopped the growth for affected users. One reporter tried disabling the bundled browser and Chrome integrations and setting BROWSER_USE_AVAILABLE_BACKENDS to an empty string in ~/.codex/config.toml, with no effect after a restart. macOS also refused to modify the handler binary even with sudo, returning "Operation not permitted".

What finally worked was killing the browser_crashpad_handler processes and making the user-level Crashpad database directory read-only and immutable. That halts the disk growth, at the cost of disabling crash reporting for the app. The issue thread also links earlier reports of stale Crashpad helpers left behind after app updates and orphaned Codex processes, hinting at a broader process-lifecycle problem in the desktop app.

Why it matters

This is a silent failure mode: the app looks and works normally while it consumes disk space at a rate that can fill tens of gigabytes within days. Users who never inspect hidden application-support directories have no obvious signal until disk pressure surfaces elsewhere.

There is also a privacy dimension. The original reporter deliberately declined to publish the minidumps because they may contain memory contents, local file paths and other private data — and in this bug, those dumps are being generated continuously and left sitting on disk rather than uploaded through a managed pipeline.

Until OpenAI ships a fix, macOS users running Codex Desktop can check the Crashpad pending directory's size and treat rapid growth as a sign they are affected. At the time of the report, there was no indication of a vendor-side fix, only the read-only workaround.