macOS: Codex Desktop/app-server appears to exhaust syspolicyd, causing spctl “Too many open files” globally

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

• #26341
• #26117
• #27136
• #26869

Powered by Codex Action

I submitted related in-app feedback with Feedback ID: 019ed2cb-eea6-7851-be4d-8be66a992d92.

My local checks on macOS 26.5.1 build 25F80 showed the same Gatekeeper/SystemPolicy failure family: spctl --assess --type execute --verbose=4 /bin/ls failed with internal error in Code Signing subsystem. The same error also occurred when assessing Codex, Cursor, a normal local Markdown file, and /opt/homebrew/bin/openai.

The visible user-facing symptom was macOS showing: "openai" is damaged and can’t be opened. You should move it to the Trash. The Homebrew OpenAI CLI still ran from Terminal (openai version 1.2.0) and codesign showed it was signed by Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2), so this did not look like a corrupted local file. It looked like the same broader SystemPolicy/Gatekeeper broken state described in this issue.

Same failure family here on macOS 26.2 (build 25C56), Codex Desktop 26.611.62324, Apple Silicon. I want to add a concrete, fixable root cause that I was able to verify on my machine, because in my case the trigger was not a respawn storm — it was the default launchctl file-descriptor limit being far too low for Codex's bundle size.

Root cause: launchctl limit maxfiles defaults to 256

syspolicyd is launched by launchd and inherits the global launchctl maxfiles soft limit, which on a stock install is just 256:

$ launchctl limit maxfiles
	maxfiles    256            unlimited

Codex.app ships a very large bundle. On my install it has 7898 Sealed Resources, dominated by an embedded Node runtime:

$ codesign -dvv /Applications/Codex.app 2>&1 | grep "Sealed Resources"
Sealed Resources version=2 rules=13 files=7898

# where those files come from:
6200  Contents/Resources/cua_node        # full Node.js dist incl. include/*.h headers + bundled npm
 934  Contents/Resources/plugins
 655  Contents/Resources/app.asar.unpacked

When Gatekeeper assesses this bundle, syspolicyd opens a large number of files at once and blows past the 256 soft limit, after which every assessment fails with EMFILE globally — exactly the symptoms in this thread (/bin/ls, DMGs, unrelated apps all reported "damaged" / Too many open files). Note the system file table is nowhere near full when this happens:

$ sysctl kern.num_files kern.maxfiles
kern.num_files: 13102
kern.maxfiles: 184320      # ~7% used

So it is not global FD exhaustion — it's the per-daemon 256 soft cap being too small for a 7898-file bundle. codesign --verify passes (it doesn't fan out across all sealed files the same way), which is why the bundle is valid yet spctl fails.

Fix that worked for me (and held)

Raising the launchctl limit and restarting syspolicyd resolved it completely in my case:

$ sudo launchctl limit maxfiles 65536 524288
$ sudo killall -HUP syspolicyd

After this, 5 consecutive spctl -a /Applications/Codex.app runs all returned accepted, Codex and VS Code launched normally, and syspolicyd CPU dropped from ~59% back to ~1%. Crucially, it stayed fixed after launching Codex — re-assessing repeatedly kept passing.

To make it survive reboot I added a LaunchDaemon:

<!-- /Library/LaunchDaemons/limit.maxfiles.plist -->
<plist version="1.0"><dict>
  <key>Label</key><string>limit.maxfiles</string>
  <key>ProgramArguments</key>
  <array>
    <string>launchctl</string><string>limit</string><string>maxfiles</string>
    <string>65536</string><string>524288</string>
  </array>
  <key>RunAtLoad</key><true/>
</dict></plist>

Caveat

In my case Codex's main process was stable (single PID, no respawn loop), so raising maxfiles was a genuine fix. For the reports here where Codex is also doing a posix_spawn storm of its own GUI binary (#26869 and others), raising maxfiles will only delay exhaustion — that part still needs an app-side backoff/retry cap.

Suggestions for the Codex team

1. Shrink the bundle. cua_node ships ~2755 .h headers and a full bundled npm (with its own node_modules) that aren't needed at runtime. Trimming dev artifacts / archiving JS into asar would drop the sealed-resource count dramatically and ease the pressure on syspolicyd.
2. Consider documenting the launchctl limit maxfiles workaround for affected macOS users until the bundle is slimmed down.

Environment for the record: macOS 26.2 (25C56), Codex 26.611.62324, Apple Silicon, SIP enabled, Gatekeeper enabled.

Update (2026-06-19): My earlier claim that raising maxfiles to 65536 "fixed it and held" was premature. While it significantly reduces the frequency (from minutes to hours), the underlying issue — codex app-server continuously spawning the GUI binary and triggering Gatekeeper assessments without backoff — still causes intermittent syspolicyd CPU churn (saw 159%!) and transient FD spikes. When saturated, syspolicyd fails globally again.

Root cause confirmed (matches #16767, #26869): codex app-server's unbounded posix_spawn + no-cache assessments drive syspolicyd into CPU runaway. Raising maxfiles helps but doesn't fix the app-side bug.

Practical mitigation: Quit Codex Desktop (Cmd+Q) when not in use. The CLI (codex exec) doesn't run app-server persistently. For those keeping it open, I wrote a watchdog that auto-restarts syspolicyd when CPU/RSS spikes: https://github.com/zyzhou9/my-claude-work/tree/master/scripts

Apologies for the earlier overconfidence — this is genuinely a tough one to pin down.

Adding another sanitized data point that appears to match this issue exactly.

Environment

macOS: 26.6 (25G5043d)
Architecture: arm64
SIP: enabled
Gatekeeper: assessments enabled
Codex Desktop: 26.616.31447
Codex CFBundleVersion: 4133
Codex Team ID: 2DC432GLL2

Codex.app itself verifies as signed/notarized:

Executable=/Applications/Codex.app/Contents/MacOS/Codex
Identifier=com.openai.codex
Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
Notarization Ticket=stapled

User-visible impact

Unrelated apps and DMGs started showing macOS "damaged and can't be opened" dialogs. The affected items were not actually corrupt:

• Official Stremio DMG: hdiutil verify reported checksum ... is VALID.
• Telegram.app: codesign --verify --deep --strict passed; signed by TELEGRAM MESSENGER LLP (6N38VWS5BX); notarization ticket stapled.
• Visual Studio Code Insiders: codesign --verify --deep --strict passed; signed by Microsoft Corporation (UBF8T346G9); notarization ticket stapled.

Yet Gatekeeper/SystemPolicy failed with:

spctl: Too many open files

For VS Code Insiders specifically, LaunchServices could spawn/check in the app, then AppleSystemPolicy killed it shortly after:

ApplicationManager: Checked in app : Visual Studio Code - Insiders
ASP: Security policy would not allow process: <pid>, /Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Code - Insiders
CAS notification for appDeath for com.microsoft.VSCodeInsiders

So the downstream failure was not just a stale Finder dialog. macOS policy enforcement actively killed an unrelated signed/notarized app after launch.

syspolicyd / AppleSystemPolicy evidence

The system-wide file table was not close to full:

launchctl limit maxfiles
  maxfiles    256            unlimited

kern.num_files: ~9k-13k
kern.maxfiles: 368640
kern.maxfilesperproc: 184320

Representative unified-log lines:

syspolicyd: UNIX error exception: 24
syspolicyd: Failed to generate SecStaticCode for <private> error: 100024
syspolicyd: not allowed to create a new connection (existing Connection ...)
syspolicyd: nw_socket_initialize_socket Failed to create socket(2,2) [24: Too many open files]
ASP: Security policy would not allow process: <pid>, /Applications/Codex.app/Contents/MacOS/Codex

In one 10-minute sample while Codex Desktop was running, filtered logs counted approximately:

Codex main-executable policy denials: 19,461
code_sign_clone denials: 22
AppleSystemPolicy security denials: 19,410
provenance sandbox failures: 1,350
EMFILE lines: 1

In a later 60-second sample, while the machine was already in the bad state, there were about:

AppleSystemPolicy security denials: 4,157
EMFILE lines: 1

Recovery behavior

• Reboot had previously restarted syspolicyd, but the issue recurred after Codex Desktop was running again.
• sudo launchctl kickstart -k system/com.apple.security.syspolicy was blocked by SIP:

Could not kickstart service "com.apple.security.syspolicy": 150: Operation not permitted while System Integrity Protection is engaged

• Quitting Codex Desktop and rebooting is currently the practical recovery path for this user.
• Reopening Codex Desktop is expected to retrigger the failure.

Notes

This does not look like corruption of Stremio, Telegram, or VS Code Insiders. It looks like Codex Desktop repeatedly triggering macOS SystemPolicy assessment of its own executable/helpers until syspolicyd enters an EMFILE/broken-state condition, after which unrelated signed/notarized apps and DMGs are rejected or killed.

A useful product-side mitigation would be a safe mode / feature-disable path that avoids high-risk helper/plugin startup, plus bounded retry/backoff around any path that can trigger repeated policy assessment of /Applications/Codex.app/Contents/MacOS/Codex or code_sign_clone/.../Codex.app.bundle/Contents/MacOS/Codex.

I hit a very similar failure mode, but in my case the strongest local signal was the Computer Use / SkyComputerUse runtime rather than only codex-execve-wrapper.

Symptoms

• Multiple unrelated macOS apps started launching very slowly or failed to launch.
• Chrome eventually stopped launching normally.
• Some freshly downloaded DMGs also failed to open.
• syspolicyd / trustd showed sustained high CPU.
• spctl returned Too many open files for otherwise valid apps.

Example:

spctl -a -t execute -vvv "/Applications/Google Chrome.app"
# /Applications/Google Chrome.app: Too many open files

After recovery, the same check returned:

/Applications/Google Chrome.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Google LLC (EQHXZ8M8AV)

Important observation

Disabling the Computer Use plugin was not sufficient by itself.

I had:

[plugins."computer-use@openai-bundled"]
enabled = false

[features]
computer_use = false

but Codex Desktop still restored a user-level runtime app under:

~/.codex/computer-use/Codex Computer Use.app

and it could also write back a notify hook pointing to:

~/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient

That means Computer Use can still be invoked indirectly through:

notify = [".../SkyComputerUseClient", "turn-ended"]

even when the plugin itself appears disabled.

Workaround that stabilized my machine

This is not a product fix, but it stopped the recurrence locally.

1. Remove the notify = [...SkyComputerUseClient..., "turn-ended"] line from ~/.codex/config.toml.

1. Keep Computer Use disabled while leaving browser-related plugins enabled:

[plugins."computer-use@openai-bundled"]
enabled = false

[plugins."browser@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = true

[features]
computer_use = false

1. Kill any existing Computer Use runtime processes:

pkill -TERM -f 'SkyComputerUse|Codex Computer Use|SkyComputerUseClient' 2>/dev/null || true
sleep 2
pkill -KILL -f 'SkyComputerUse|Codex Computer Use|SkyComputerUseClient' 2>/dev/null || true

1. If Codex Desktop keeps restoring and launching the user-level runtime, block only the user-level Computer Use executables. Do not modify /Applications/Codex.app, since that can break the app signature.

svc="$HOME/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService"
cli="$HOME/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient"

for f in "$svc" "$cli"; do
  chflags nouchg "$f" 2>/dev/null || true
  chmod 000 "$f"
  chflags uchg "$f"
done

1. Reboot macOS. In my case, rebooting was necessary once syspolicyd had already entered the broken state. Trying to restart com.apple.security.syspolicy directly was blocked by SIP.

1. After reboot, verify:

pgrep -alf 'SkyComputerUse|Codex Computer Use|SkyComputerUseClient' || true
spctl -a -t execute -vvv "/Applications/Google Chrome.app"

Expected:

• no real SkyComputerUseService / SkyComputerUseClient process
• no Too many open files
• spctl returns accepted

Reverting the workaround

If you want to re-enable Computer Use later:

for f in "$svc" "$cli"; do
  chflags nouchg "$f" 2>/dev/null || true
  chmod 755 "$f"
done

Then re-enable Computer Use from Codex settings/config and restart Codex.

Suggested product-side fix

Codex Desktop should probably not auto-install, auto-restore, launch, or write a notify hook for Computer Use when:

• [features].computer_use = false, or
• [plugins."computer-use@openai-bundled"].enabled = false

Also, uninstalling/disabling Computer Use should remove or ignore any notify hook that points to SkyComputerUseClient.

The key issue here is that the visible plugin state and the actual user-level Computer Use runtime state can diverge. When they diverge, SkyComputerUseClient may still be invoked and can contribute to the same global Gatekeeper / syspolicyd failure pattern described in this issue.

This is a huge problem and renders codex app unusable on my machine.

I encountered this syspolicyd problem yesterday on a very fresh version:
Version 26.616.71553 • Released Jun 23, 2026

I tried many ways I can find in all comments from all issues I can found but no one works.
Until I found a stray/corrupted .git folder under one of my codex working directory, which contains multiple repos (but it should not have its own .git).

$ find .
.
./objects
./objects/pack
./objects/pack/tmp_idx_10pAga
./objects/pack/tmp_idx_TqD4PQ

I removed it and everything is fine now.

After open Codex App, syspolicyd will run at ~50% for only couple seconds, not infinitively 150% anymore.
computer use, browsers, etc. are all enabled.

Hope this helps.

Yes, it was caused by empty .git folders from syncthing on my machine. Codex should handle this gracefully without essentially rendering your OS unusable.

Reproduced this today (2026-07-16) via the ChatGPT macOS app (not the standalone Codex.app), which bundles the same codex app-server. Adding a data point that may help narrow the root cause:

Timeline (sampled every 15s):

• Before ChatGPT launch: syspolicyd idle at 0-0.3% CPU, no hung processes.
• Within ~15-20s of launching ChatGPT: syspolicyd CPU jumped to 81.4%, 2 new processes stuck at <=128KB RSS (dyld startup stage).
• Over the next ~90s: stuck process count grew from 1 to 4, new-process spawn latency increased.
• A completely unrelated process (brew shellenv invoked by zsh login startup) got stuck for 4.5 minutes at 32KB RSS, blocking Terminal from presenting a shell prompt at all.

New finding - quitting the app is not sufficient:
killall ChatGPT (or quitting normally) only kills the top-level app. The codex app-server process (/Applications/ChatGPT.app/Contents/Resources/codex ... app-server --analytics-default-enabled) gets reparented to launchd (PPID becomes 1) and keeps running and keeps spawning new node_repl children (observed count grow from 2 to 3 with zero user interaction after the app was quit). syspolicyd stayed pegged at ~54% the whole time it was orphaned.

Only after manually kill -9-ing the orphaned app-server PID (and its remaining children) did syspolicyd CPU drop to 0% and system-wide process spawn latency return to normal.

This suggests the fix needs to cover two things: (1) the exec/validation cost per the analysis in #19885, and (2) proper process-group cleanup on app quit so app-server doesn't outlive its parent as an orphan.