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

Resolved 💬 3 comments Opened Jun 3, 2026 by zhyuzhyu Closed Jun 3, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

3 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25882
  • #25243
  • #25719

Powered by Codex Action

zhyuzhyu · 2 months ago

Post-filing live update from the same machine:

The issue is still active after filing. A system launchd monitor is currently sampling syspolicyd with root lsof.

Latest live snapshot:

2026-06-03 17:07:37 syspolicyd_pid=489 total_fd=2575 codex_main_fd=2535 max_fd=2559 emfile_last_60s=0 driver_error_last_60s=2

The current lsof temp snapshot has 2,576 lines, including 2,535 descriptors to the Codex main executable:

codex_fd_count=2535
min_codex_fd=17
max_codex_fd=2559

Example entries:

syspolicy 489 root   17r REG ... /Applications/Codex.app/Contents/MacOS/Codex
syspolicy 489 root   18r REG ... /Applications/Codex.app/Contents/MacOS/Codex
syspolicy 489 root   19r REG ... /Applications/Codex.app/Contents/MacOS/Codex
syspolicy 489 root   21r REG ... /Applications/Codex.app/Contents/MacOS/Codex
syspolicy 489 root   24r REG ... /Applications/Codex.app/Contents/MacOS/Codex

Timeline from the monitor:

first sample:               2026-06-03 16:13:34 syspolicyd_pid=489 total_fd=35 codex_main_fd=0 max_fd=26
last sample before spike:    2026-06-03 16:40:27 syspolicyd_pid=489 total_fd=1024 codex_main_fd=983 max_fd=1008
first codex_main_fd >=1000:  2026-06-03 16:40:33 syspolicyd_pid=489 total_fd=1396 codex_main_fd=1355 max_fd=1380
current max observed:        total_fd=2576 codex_main_fd=2536 max_fd=2559

This confirms the recurrence after reboot and after the original report: syspolicyd is again pinned near its fd limit, and the retained descriptors are almost entirely references to /Applications/Codex.app/Contents/MacOS/Codex.

guidedways contributor · 2 months ago