Codex Desktop macOS high CPU: orphan Crashpad from installer volume plus respawning GPU process drives syspolicyd EMFILE

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.602.40724
Chromium base 149.0.7827.54

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS on Apple Silicon (arm64)

What issue are you seeing?

This is a related but slightly narrower field report for the existing macOS syspolicyd / Too many open files reports, especially #25243, #25882, #26341, and #16767.

In this incident, the visible symptom was a local CPU runaway involving three process families at once:

• syspolicyd above ~150% CPU
• two browser_crashpad_handler processes each above ~100% CPU
• Codex (Service) --type=gpu-process around ~90-100% CPU

The investigation found two distinct Codex-related contributors:

1. Orphaned Crashpad handlers from the installer volume

The hottest browser_crashpad_handler processes were not children of the currently installed app. Their executable path came from the temporary installer volume:

``text
/Volumes/Codex Installer/Codex.app/.../browser_crashpad_handler
``

Their parent had become launchd, and the corresponding Codex Installer volume was no longer present in the current mount list. In other words, a Codex instance launched from the installer volume had left Crashpad monitor processes behind after the volume disappeared.

Sending normal termination did not clear them. Force-ending those installer-volume Crashpad processes stopped that part of the CPU spike, and they did not immediately return.

1. The currently installed Codex app kept respawning a hot GPU service

After the orphan Crashpad handlers were gone, the current installed app still had a stable hot process:

``text
/Applications/Codex.app/.../Codex (Service) --type=gpu-process
``

Killing that GPU process caused Codex to immediately recreate it, and the new GPU process returned to ~100% CPU. This made it look like a deterministic failure of the current GPU/Chromium/Electron path, not a single stuck helper.

Temporarily stopping the GPU process with SIGSTOP immediately reduced that process to 0% CPU. The tradeoff is that the GUI may stall or retry the GPU channel, but it was useful as emergency triage to stop the CPU burn without quitting the whole Codex app.

At the same time, Gatekeeper / syspolicyd showed the same EMFILE signature as the related issues:

/Applications/Codex.app: Too many open files
UNIX error exception: 24
Failed to generate SecStaticCode ... error: 100024
Security policy would not allow process: ..., /Applications/Codex.app/Contents/MacOS/Codex

Because SIP was enabled, trying to restart com.apple.security.syspolicy directly was blocked by the OS. The practical mitigation was to stop feeding the policy daemon more Codex-related process churn, then restart Codex later with hardware acceleration disabled and GPU/Shader/Dawn caches cleared.

What steps can reproduce the bug?

I do not yet have a clean minimal reproduction, but the observed incident path was:

1. Have Codex Desktop installed under /Applications/Codex.app.
2. At some prior point, launch or update Codex from a mounted Codex Installer volume.
3. Later, after the installer volume is gone, observe high CPU in Activity Monitor.
4. Check process paths and parent processes.
5. Notice browser_crashpad_handler processes still running from /Volumes/Codex Installer/Codex.app/... with parent launchd.
6. Kill those orphan installer-volume Crashpad handlers.
7. Observe the remaining current-app process: Codex (Service) --type=gpu-process around ~100% CPU.
8. Kill that GPU process and observe that Codex immediately respawns it and the new GPU process returns to ~100% CPU.
9. Run spctl -a -vvv -t execute /Applications/Codex.app or inspect unified logs and observe the Too many open files / error 24 / 100024 syspolicyd pattern.

What is the expected behavior?

• Crashpad handlers created by a Codex instance launched from a mounted installer volume should not survive indefinitely after the app instance exits or the volume disappears.
• If a Crashpad monitor loses its parent or its app bundle path disappears, it should exit rather than spin at high CPU.
• The GPU service should not respawn into a stable ~100% CPU loop.
• If the GPU process repeatedly crashes, hangs, or burns CPU, Codex should back off and fall back to software rendering / safe mode instead of continuously recreating a hot GPU service.
• Codex should not drive syspolicyd into EMFILE / Too many open files conditions.

Additional information

Workaround that appeared reasonable for this machine:

• Do not run Codex directly from the .dmg / installer volume for normal use.
• If browser_crashpad_handler is hot, inspect its executable path before treating all Crashpad processes as the same bug.
• If the hot path is /Volumes/Codex Installer/Codex.app/..., treat it as an orphaned installer-volume helper.
• If the hot path is the installed app's Codex (Service) --type=gpu-process and it respawns hot after kill, disable hardware acceleration for next launch and clear GPU/Shader/Dawn caches.

A longer public postmortem with sanitized notes is here: https://aiya.de5.net/t/topic/215/1

Related issues I found before filing:

• #25243
• #25882
• #26341
• #16767