lyf-fk
June 16, 2026, 7:29am
1
Codex Desktop started triggering a severe macOS syspolicyd runaway after the latest update. This is the desktop app, not the CLI.
Environment:
macOS on Apple Silicon
Codex Desktop: 26.609.71450
CFBundleVersion: 3965
App path: /Applications/Codex.app
Gatekeeper assessments: enabled
SIP/Gatekeeper were not disabled
Symptoms:
Launching Codex Desktop causes syspolicyd to climb to 120% to 250% CPU.
Codex itself also spikes CPU while this is happening.
spctl --assess --type execute --verbose=4 /Applications/Codex.app returns:
/Applications/Codex.app: Too many open files
lsof shows thousands of syspolicyd file descriptors pointing to the same Codex executable:
/Applications/Codex.app/Contents/MacOS/Codex
Observed counts:
syspolicyd FD count for the Codex executable: approximately 2538 to 2540
launchctl maxfiles was raised to 65536 / unlimited and persisted through /Library/LaunchDaemons/local.maxfiles.plist
Raising maxfiles reduces the immediate FD-limit failure mode, but syspolicyd still returns to high CPU after Codex is launched.
Rebooting macOS does not resolve the issue once Codex Desktop is opened again.
Things already tried:
sudo xattr -cr /Applications/Codex.app
sudo killall syspolicyd
sudo kill -9 $(pgrep -x syspolicyd)
sudo launchctl limit maxfiles 65536 184320
Current result:
syspolicyd is relaunched by macOS and resumes the evaluation loop.
The repeated FD target is still /Applications/Codex.app/Contents/MacOS/Codex.
I do not want to disable SIP or globally disable Gatekeeper for this.
This looks like Codex Desktop is repeatedly triggering Gatekeeper / syspolicy executable assessment and leaking or retaining FDs in syspolicyd. Please route this to the Desktop App team if this forum is the right place; if there is a better Desktop-specific issue tracker, please point me there.
VeitB
June 16, 2026, 7:38am
2
Hi and welcome to the community!
Similar issues have been reported on GitHub. You can add your voice there to help the team triage the urgency.
I think this is a very close match, but there are more equivalent reports:
opened 04:28PM - 02 Jun 26 UTC
closed 08:07PM - 12 Jun 26 UTC
bug
app
performance
### What version of the Codex App are you using (From “About Codex” dialog)?
26… .527.60818 (3437)
### What subscription do you have?
ChatGPT Pro
### What platform is your computer?
Darwin 25.1.0 arm64 arm
### What issue are you seeing?
[codex-syspolicyd-bug-report.md](https://github.com/user-attachments/files/28518151/codex-syspolicyd-bug-report.md)
## Describe the bug
The Codex macOS desktop app repeatedly tries to `exec` its own main executable
(`/Applications/Codex.app/Contents/MacOS/Codex`) **tens of times per second**. Every attempt is
denied by the kernel's AppleSystemPolicy (Gatekeeper) and triggers a code-signature /
online-notarization evaluation in the system daemon `syspolicyd`.
`syspolicyd` has a default soft file-descriptor limit of only **256**. The flood saturates it
within minutes; from then on `syspolicyd` fails **every** Gatekeeper evaluation with `EMFILE`
(errno 24), so **no app on the machine can be launched** until `syspolicyd` is force-restarted
(`sudo killall syspolicyd`). The recovery is only temporary — Codex refills the descriptors
again within minutes.
This is effectively a system-wide denial of service caused by the Codex app. The app's code
signature itself is valid and notarized; this is a runaway-relaunch bug, not a signing problem.
## Steps to reproduce
1. Launch the Codex macOS desktop app and leave it running.
2. Wait a few minutes (no user action required; the machine does not need to be launching apps).
3. Observe that the app can no longer open — and that **no other app can open either**.
Confirmed deterministic: **killing the Codex app stops the storm instantly and the system
recovers; re-opening it brings the storm back.** Verified 3 separate times.
## Expected behavior
The app launches its main binary exactly once; helper/agent processes are spawned through the
normal Chromium/Electron paths. `syspolicyd` stays near idle when the user is not launching apps.
## Actual behavior
The app issues `posix_spawn` of its own main GUI binary tens of times per second in a loop, each
denied by Gatekeeper, until the OS-wide Gatekeeper daemon (`syspolicyd`) runs out of file
descriptors and denies all process executions system-wide.
Open/close correlation (same machine, same commands, only variable = Codex running):
| Metric (per ~15–20 s window) | Codex running | Codex killed |
|---|---|---|
| `MacOS/Codex` Gatekeeper denials | 223 / 20 s | **0** |
| `syspolicyd` "process died mid-eval" | 443 / 15 s | **1** |
| online notarization checks (`api.apple-cloudkit.com`) | ~230 / 15 s | **1** |
| `spctl -a Calculator.app` | `Too many open files` | `accepted` |
| any app launches | frozen | normal |
## Logs / evidence (raw, unedited)
**A. Codex main binary denied ~tens of times/sec** (6 attempts within 0.0002 s, sequential PIDs;
**31,273** such denials in a single 30-minute window):
2026-06-02 23:46:55.723512+0800 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 24230, /Applications/Codex.app/Contents/MacOS/Codex
2026-06-02 23:46:55.723574+0800 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 24231, /Applications/Codex.app/Contents/MacOS/Codex
2026-06-02 23:46:55.723578+0800 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 24232, /Applications/Codex.app/Contents/MacOS/Codex
2026-06-02 23:46:55.723666+0800 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 24233, /Applications/Codex.app/Contents/MacOS/Codex
2026-06-02 23:46:55.723693+0800 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 24234, /Applications/Codex.app/Contents/MacOS/Codex
2026-06-02 23:46:55.723718+0800 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 24235, /Applications/Codex.app/Contents/MacOS/Codex
**B. `syspolicyd` running out of file descriptors** (`error: 100024` and `UNIX error exception:
24` both encode `EMFILE`):
2026-06-02 23:47:40.014954+0800 syspolicyd: (Security) [com.apple.securityd:security_exception] UNIX error exception: 24
2026-06-02 23:47:40.014986+0800 syspolicyd: [com.apple.syspolicy:default] Failed to generate SecStaticCode for error: 100024
**Commands to reproduce the observation (run while the app is open):**
```bash
# Watch the relaunch storm live:
log stream --predicate 'eventMessage CONTAINS "would not allow" AND eventMessage CONTAINS "MacOS/Codex"'
# Count denials of the Codex main binary over the last 15s:
log show --predicate 'senderImagePath CONTAINS "AppleSystemPolicy"' --last 15s | grep -c "MacOS/Codex"
# See syspolicyd exhausting file descriptors:
log show --predicate 'process == "syspolicyd" AND eventMessage CONTAINS "100024"' --last 1m | grep -c 100024
# Confirm Gatekeeper is wedged system-wide:
spctl -a -vv /System/Applications/Calculator.app # -> "Too many open files" during the storm
Additional context
Already ruled out:
- Not network/proxy. Failure-type split: timed out = 0, refused = 0; failures are
"process died before evaluation completed". api.apple-cloudkit.com is DIRECT and answers in
~0.15 s.
- Not the Computer Use feature. Disabling it did not change the storm (~11 MacOS/Codex/s
continued). Only fully quitting the app stopped it.
- Not code signing. codesign -v /Applications/Codex.app passes; validly signed & notarized.
Note on diagnosis: the denied processes die within microseconds, so they are invisible to
ps, and execsnoop/DTrace cannot capture the spawning parent because SIP blocks DTrace probes.
The exact internal caller must be found from Codex's own source/instrumentation.
Suggested investigation: look for watchdog / relaunch / single-instance-recovery /
auto-update (Sparkle) / agent-restart logic that may open/posix_spawn the app's own main
executable in a retry loop when a launch is denied or a child exits unexpectedly. The retry
appears to have no backoff and no cap, which turns one failed launch into a system-wide DoS.
Workaround for affected users: quit the Codex app, then sudo killall syspolicyd.
---Full original report (backup): [codex-syspolicyd-bug-report.md](https://github.com/user-attachments/files/28518151/codex-syspolicyd-bug-report.md)
### What steps can reproduce the bug?
This is a desktop-app-level bug (runaway relaunch of the app's own main binary), not tied to a CLI session — so session id / token limit / context window usage are N/A.
Steps to reproduce:
1. Launch the Codex macOS desktop app (`/Applications/Codex.app`) and just leave it running. No prompt, no task, no user action is required.
2. Wait a few minutes.
3. Try to open any app (Codex itself, or e.g. Calculator) — launches freeze system-wide.
How to observe it:
```bash
# Live storm: Codex's own main binary denied by Gatekeeper tens of times/sec
log stream --predicate 'eventMessage CONTAINS "would not allow" AND eventMessage CONTAINS "MacOS/Codex"'
# syspolicyd running out of file descriptors (EMFILE / error 100024)
log show --predicate 'process == "syspolicyd" AND eventMessage CONTAINS "100024"' --last 1m | grep -c 100024
# Gatekeeper wedged system-wide:
spctl -a -vv /System/Applications/Calculator.app # -> "Too many open files" during the storm
Deterministic correlation (only variable = Codex running):
- Codex running -> ~223 MacOS/Codex Gatekeeper denials / 20 s; all app launches frozen.
- Codex killed (killall Codex) -> denials drop to 0; system recovers instantly.
- Re-opening Codex brings the storm back. Verified 3 separate times.
Recovery / workaround: quit the Codex app, then sudo killall syspolicyd.
## What is the expected behavior?（选填，但建议填）
粘贴这段：
```markdown
The app launches its main binary exactly once at startup; any helper/agent processes are spawned through the normal Chromium/Electron paths.
`syspolicyd` stays near idle when the user is not launching apps, and never exhausts its file descriptors.
If a launch/exec of a child is ever denied or a child exits unexpectedly, the relaunch logic should use exponential backoff and a hard retry cap — never retry tens of times per
second indefinitely, which turns one failed launch into a system-wide DoS.
### What is the expected behavior?
_No response_
### Additional information
_No response_