Codex Desktop hid 323 GB of crash dumps on one Mac

A Codex Desktop user found about 323 GB of crash dumps on a 926 GB Mac, roughly 35% of the disk, before free space ran out. The user posted the measurements on October 17 to an older GitHub issue about the same bug. Free space had dropped to 1.4 GB. The app showed no warning and kept working the whole time.

The measurements were taken October 15 to 17 on ChatGPT.app 26.1007.71326 (build 20398), running macOS 15.7.4 on Apple Silicon. The dumps were in two folders:

• ~/Library/Application Support/com.openai.codex/web/Crashpad: 180 GB, 2,251,765 files
• ~/Library/Application Support/Codex/Crashpad: 143 GB, 1,785,095 files, almost all of them in pending/

That comes to about 4.04 million files. The author found them only by running du over ~/Library.

Crashpad is the crash reporter that ships with Chromium-based apps. When a process dies, Crashpad writes a snapshot of its state and keeps it in a pending folder for later analysis. The author links the flood to a loop described in a related issue on build 26.727.51351. In that loop, browser_crashpad_handler hits a SIGTRAP 2ms after launch, launchd starts it again, and the pending folder grows by about 17 GB a day.

When the issue was first filed, on Codex 26.527.60818, the pending folder grew to 4.9 GB and 54,504 files in a single day. Those files came in pairs, one .dmp and one _sidecar.json. That first reporter found two handler processes running with PPID=1 since May 30, both writing to the same Crashpad database. While they investigated, the count of pending files went from 53,444 to 54,064 to 54,504. They did not post any minidumps publicly because the files may contain memory contents, local paths or private data. On June 9 the issue title was changed to say the dumps grow “without any limit: +5GB per day at least.”

Other users have reported the same thing. On the OpenAI Developer Community forum, a Mac user wrote on July 24 that the app had used up about 30 GB of free space in roughly a week. That user had to empty the Crashpad pending folder and said the problem had been going on for at least a month. In another GitHub issue, on build 26.928.21956, the pending folder reached about 168 GB. After the reporter cleared it, it kept growing during normal use of the desktop app (the CLI was not involved). That reporter said the trigger and the component writing the dumps were unknown.

On September 7, OpenAI Support wrote on the forum that it could not confirm a Crashpad-specific fix yet. It asked for app and macOS versions, the folder path and the growth rate. In the 168 GB case, support advised clearing the pending reports with the app closed and keeping the app updated, and offered build 26.1002.52244. That reporter did not confirm whether the problem happened again on that build. The 323 GB report comes from 26.1007.71326, a later build. OpenAI’s recent change that cut on-disk storage by 60% changed how the apps store state and did not address these dumps.

The issue asks for three changes. The first is a size or count cap on Crashpad/pending with automatic pruning. The second is a fix for the handler crash loop that produces the dumps. The third is an in-app warning once the app’s own data goes over a few GB.

The author has already cleared the space. With the app still running, they renamed both Crashpad folders and then deleted the renamed copies. Free space went from 1.4 GB to more than 50 GB within minutes. Because there are millions of small files, the delete was still running when the update was posted.