macOS syspolicyd leaks file descriptors while repeatedly assessing Codex.app executable

Resolved 💬 3 comments Opened Jun 3, 2026 by zhyuzhyu Closed Jun 3, 2026

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.
  • spctl can fail with too many open files while syspolicyd is exhausted.
  • Reboot clears the syspolicyd fd 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗