macOS syspolicyd leaks file descriptors while repeatedly assessing Codex.app executable
Summary
While using Codex App on macOS, syspolicyd repeatedly opens /Applications/Codex.app/Contents/MacOS/Codex and does not release the file descriptors. The count grows until syspolicyd reaches the per-process file descriptor limit, then it logs UNIX error exception: 24 and unrelated CLI startup or sandbox initialization can stall briefly.
This may include an Apple syspolicyd leak, but Codex App activity consistently triggers the recurrence on my machine.
Environment
- macOS: 26.5 (25F71)
- Architecture: arm64
- Codex App: 26.527.60818
- Binary:
/Applications/Codex.app/Contents/MacOS/Codex - Signing:
Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
Observed impact
- Short hangs during Codex startup / sandbox initialization and unrelated CLI commands.
spctlcan fail with too many open files whilesyspolicydis exhausted.- Reboot clears the
syspolicydfd count temporarily, but the leak recurs later during Codex App use.
Evidence
Before reboot, root lsof showed:
syspolicyd PID 531
total lsof lines: ~2576
fds to /Applications/Codex.app/Contents/MacOS/Codex: ~2536
max fd: 2559
After reboot the count reset to zero, then recurred:
2026-06-03 16:54:36 syspolicyd_pid=489 total_fd=2576 codex_main_fd=2536 max_fd=2559
Recent unified log snippets around recurrence:
syspolicyd: (Security) [com.apple.securityd:security_exception] UNIX error exception: 24
Failed to generate SecStaticCode ... error: 100024
failed to call driver: 0x3
sample syspolicyd showed stacks around:
com.apple.security.syspolicy.yara
SecStaticCodeCreateWithPath
Security::CodeSigning::DiskRep::bestGuess
Security::UnixPlusPlus::FileDesc::open
Codex related activity in logs around the window included many policy/TCC/provenance checks for Codex App helpers and subprocesses, including bare-modifier-monitor, codex app-server, node_repl, SkyComputerUseClient, plus repeated git, git-remote-http, node, codex, sw_vers, and sips subprocesses.
Signing and quarantine checks
These checks were clean after reboot:
codesign --verify --deep --strict --verbose=4 /Applications/Codex.app
spctl -a -vvv -t exec /Applications/Codex.app
spctl result:
/Applications/Codex.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
No quarantine xattr was present.
Reproduction / monitoring notes
The leak is not fully deterministic immediately after restart. It cleared after a system reboot, then a background monitor saw it recur later while Codex App was in use. Aggregated monitor result:
samples: 366
max codex_main_fd: 2536
samples with codex_main_fd >= 100: 140
samples with codex_main_fd >= 1000: 125
max EMFILE log count in last 60s: 36
I searched existing open and closed issues before filing and did not find a matching report for syspolicyd, file descriptor leak, SecStaticCode, AppleSystemPolicy, or UNIX error exception: 24.
Expected behavior
Codex App startup and helper/subprocess activity should not cause syspolicyd to retain thousands of open descriptors to the same Codex executable.
Request
Please investigate whether Codex App startup/helper packaging, subprocess attribution, TCC/provenance behavior, or repeated static code identity checks can be changed to reduce the policy assessment burst or avoid repeatedly assessing the main executable.
I understand syspolicyd retaining these descriptors may be an Apple bug. However, Codex App consistently triggers the recurrence here, so Codex may need a workaround or a focused report to Apple with better app-side diagnostics.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗