Codex Desktop triggers sustained syspolicyd/trustd CPU spikes on macOS

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

• #15631

Powered by Codex Action

This is happening to me as well with the same versions. Rebooting into recovery mode and launching a terminal and running csrutil disable stopped the issue, but now I am also running without System Integrity Protection.

Title: Temporary workaround for syspolicyd/trustd spikes

I found a temporary workaround for this issue: Disable the auto-update feature.

Instead of letting the app update itself, I download a fresh installation package (DMG/installer) for each new version and manually overwrite the existing app** in the /Applications folder.

This seems to bypass the repetitive signature validation loop triggered by the auto-update process. Hope this helps!

This is absolutely brutal when you're also running under something like Jamf.

Absurd that this has not been fixed yet

Still facing the same issue on the latest release 26.527.31326 (3390).
Sustained syspolicyd and trustd, as well as other apps can get stuck bouncing in the Dock without showing a window -- yep.

Possible, but temporary and somewhat inconsistent workaround: https://x.com/mylifcc/status/2057025681243222408

Some other mentions of these issues:
X post: "syspolicyd took a look, why is it all Codex?"
X post: codex app spinning infinite syspolicyd...

Hi, I can reproduce this on my Mac as well. This appears to be more than a temporary local cache issue: stopping Codex and restarting syspolicyd/trustd recovers app launching, but reopening Codex causes the issue to return.

Environment:

• macOS 26.5, build 25F71
• Codex Desktop 26.527.31326
• Codex bundle: com.openai.codex
• Codex app is signed and notarized

Observed impact:

• Figma, Claude, and Adobe Premiere Pro 2026 intermittently fail to launch.
• Finder shows the Korean equivalent of “the application cannot be opened.”
• spctl checks can fail or time out while syspolicyd is saturated.
• This effectively becomes a local denial-of-service against launching normal notarized apps.

Evidence collected:

• Before recovery, syspolicyd held /Applications/Codex.app/Contents/MacOS/Codex open about 67,820 times.
• syspolicyd CPU repeatedly reached about 160-213%.
• trustd CPU also rose with it.
• A syspolicyd sample showed physical footprint around 7.7GB and Dispatch Thread Soft Limit: 64 reached.
• Repeated logs included:
• UNIX error exception: 24
• Failed to generate SecStaticCode ... error: 100024
• failed to call driver: 0x3
• After quitting Codex and restarting syspolicyd/trustd, syspolicyd open file count returned to normal and Figma/Claude/Adobe Premiere all returned accepted from spctl -a -vvv -t execute.
• Reopening Codex later caused the high syspolicyd/trustd behavior to return.

Recent confirmation:

• recover-syspolicy-after-codex.command normalized the system.
• spctl afterward:
• /Applications/Figma.app: accepted
• /Applications/Claude.app: accepted
• /Applications/Adobe Premiere Pro 2026/Adobe Premiere Pro 2026.app: accepted
• Current workaround is to quit Codex, restart syspolicyd/trustd, then open Figma/Claude/Adobe before reopening Codex.

I have a sanitized local evidence package containing:

• syspolicyd-lsof.txt
• syspolicyd-sample.txt
• sample-command.out
• recovery reports
• spctl before/after evidence

I can provide the package if maintainers want the additional diagnostics. I am not attaching raw local paths or private logs publicly unless requested.

This aligns closely with #16767, #17516, and #19885. The #19885 hypothesis about repeated helper execution/Gatekeeper checks also matches my local observations: Codex helper processes such as codex app-server, node_repl, and Computer Use helpers were active during recurrence.

This issue makes Codex App almost unusable for me.

After launching Codex, AppleSystemPolicy rapidly logs deny events for the Codex main executable:

ASP: Security policy would not allow process: <pid>, /Applications/Codex.app/Contents/MacOS/Codex

In one short capture, this produced about 4k ASP events within ~10 seconds. Shortly after that, syspolicyd started failing with:

UNIX error exception: 24
Failed to generate SecStaticCode for <private> error: 100024

Closing Codex makes the storm stop after a short while.

Codex is repeatedly triggering macOS exec policy verification for its own main executable, which eventually pushes syspolicyd into EMFILE / Code Signing failures.

This new version seems pushed this issue even far, previously it's just cpu usage unusually high for syspolicyd, now it will push it to whole system lack of fd, which in turn will cause whole os unusable, can not execute anything in terminal, can't open any file in editor.

Title:

Codex triggers syspolicyd file descriptor leak on macOS, causing all DMG files to be reported as “damaged”

Body:

Hi,

I’m experiencing a serious issue on macOS that appears to be related to Codex.

Environment

• macOS 26.5.1 (Build 25F80)
• Apple Silicon (MacBook Air)
• Codex downloaded from the official website
• Fresh reinstall of Codex (issue persists after reinstall)

Symptoms

After launching Codex and using it for a while:

• Any DMG file downloaded from official websites starts showing:

“.dmg is damaged and can’t be opened. You should move it to the Trash.”

• This affects multiple unrelated applications (VS Code, Chrome, etc.).
• Restarting macOS temporarily fixes the issue.
• After Codex runs for some time, the issue comes back.

Investigation

I verified that the DMG files themselves are not corrupted:

hdiutil verify VSCode-darwin-arm64.dmg

Verification succeeds.

I also found that spctl eventually starts failing with:

spctl -a -vv VSCode-darwin-arm64.dmg

Output:

spctl: Too many open files

The most interesting finding is that syspolicyd continuously accumulates file descriptors pointing to Codex.

Immediately after restarting syspolicyd:

sudo lsof -p $(pgrep syspolicyd | head -1) | \
awk '{print $9}' | sort | uniq -c | sort -nr | head

Output is normal.

After running Codex:

720 /Applications/Codex.app/Contents/MacOS/Codex
1907 /Applications/Codex.app/Contents/MacOS/Codex
2015 /Applications/Codex.app/Contents/MacOS/Codex
2222 /Applications/Codex.app/Contents/MacOS/Codex

The count keeps increasing over time.

Example:

2222 /Applications/Codex.app/Contents/MacOS/Codex

Almost all open descriptors inside syspolicyd are associated with the Codex executable.

Additional observation

If I completely quit Codex:

1. sudo killall syspolicyd
2. Wait for macOS to restart syspolicyd

The file descriptor count returns to normal and DMG files can be opened again.

If I launch Codex again, the descriptor count starts growing and eventually the “damaged DMG” problem returns.

Expected behavior

Launching Codex should not cause syspolicyd to continuously accumulate references to the Codex executable or eventually break Gatekeeper verification for unrelated applications.

Question

Has anyone seen similar behavior?

Is there a known issue between Codex and Gatekeeper (syspolicyd) on recent macOS versions?

I’m happy to provide additional logs or run diagnostic commands if needed.

Thanks.

Confirming this on macOS 26.4.1 (25E253), Codex 149.0.7827.54, MacBook Pro 14" M1 Pro / 16 GB. Adding two data points on the mechanism + a workaround that actually held.

Setup: Codex Desktop running alongside a launchd-based orchestrator (~11 daemons) that fires codex exec agents continuously, plus a few Claude Code sessions. Uptime ~3 days.

Symptoms (match this thread):

• syspolicyd pinned at 80–95% CPU, RSS bloated to ~700 MB (normal 20–50 MB)
• trustd ~29% CPU
• App launches serialized behind it: Chrome ~10 min to open, a video player ~4 min, login spinner several minutes. On an M1 Pro — clearly not raw compute.

Mechanism observed: the temp wrapper executables Codex spawns in ~/.codex/tmp/path/codex-arg0XXXXXX/ (applypatch / apply_patch) get a new random name on every invocation, so Gatekeeper can never reuse a cached assessment — each spawn triggers a full signature + notarization evaluation. With agents firing nonstop, syspolicyd enters the AppleSystemPolicy retry loop and spins on its own.

Important for anyone debugging: once it's in the loop, killing the spawner alone is not enough — the loop is self-sustaining. sudo killall syspolicyd by itself also doesn't help: it respawns and gets re-saturated within ~4 minutes while agents keep producing temp binaries. What fixed it without a reboot:

1. quit Codex Desktop + stop the agent daemons (remove the spawner), then
2. sudo killall syspolicyd

→ syspolicyd back to 0% CPU / ~25 MB, launches instant again.

A stable fix would be using a fixed, properly-signed path for these wrapper binaries instead of randomly-named temp executables, so Gatekeeper can cache the assessment.

I can reproduce a very similar pattern on a newer build.

Environment:

• macOS 27.0, build 26A5353q, arm64
• Codex Desktop 26.611.61753
• Codex bundle: com.openai.codex
• Mole 1.7.1 was only used as the process monitor

Observed during a live session:

• Mole showed syspolicyd and trustd near the top of CPU usage.
• A separate process sample showed syspolicyd around 51% CPU and trustd around 30% CPU.
• Memory pressure was normal, swap was 0, and macOS reported no thermal or performance warning.
• In a 3-minute unified-log window, I saw about 16k SecKeyVerifySignature entries from syspolicyd/trustd.
• The same log window also included AppleSystemPolicy deny events for the Codex main executable, for example:

ASP: Security policy would not allow process: <pid>, /Applications/Codex.app/Contents/MacOS/Codex

I also see active temp arg0 wrappers under:

~/.codex/tmp/arg0/codex-arg0*/applypatch
~/.codex/tmp/arg0/codex-arg0*/apply_patch
~/.codex/tmp/arg0/codex-arg0*/codex-execve-wrapper

Those entries are symlinked back to:

/Applications/Codex.app/Contents/Resources/codex

Some of those wrapper directories were created during the same spike. This looks consistent with the repeated Codex helper/wrapper execution path triggering macOS policy/signature validation, rather than general system load or memory pressure.

Workaround that worked for me: remove the quarantine flag

I discovered this fix together with an AI assistant (Claude). syspolicyd was peaking at ~280% CPU immediately after launching Codex.

xattr -dr com.apple.quarantine /Applications/Codex.app

Then restart Codex. If syspolicyd is already spinning, also run:

sudo killall syspolicyd

It will restart automatically and should calm down within seconds.

What this does: macOS adds a quarantine flag to all downloaded apps. Gatekeeper uses syspolicyd to repeatedly verify flagged files on each launch/execution. Removing the flag stops this verification cycle for the main app bundle.

Is it safe? Yes — you're removing metadata only, not modifying the app itself. The quarantine flag's purpose (warning about internet downloads) is already fulfilled the first time you launch the app.

Important caveat: Based on other comments here, the deeper root cause seems to be that Codex spawns temp wrapper executables with random names under ~/.codex/tmp/arg0/, which prevents Gatekeeper from caching assessments and triggers a full signature check on every spawn. This fix addresses the quarantine flag on the main bundle, but may not fully resolve the issue under heavy agent workloads. For some users it may only be a partial or temporary relief.

Note: The flag returns after each Codex update (macOS re-adds it when a new file is downloaded), so you may need to repeat this after updates.

Update on my previous comment — more complete fix

After further testing (including a Mac restart), I found that removing the quarantine flag alone is not always enough. Here is the complete workaround that has held stable for me:

1. Quit Codex first — important, otherwise it keeps generating new temp wrappers faster than the fix can work.

2. Remove quarantine flags:

xattr -dr com.apple.quarantine /Applications/Codex.app
xattr -dr com.apple.quarantine ~/.codex/ 2>/dev/null

3. Enable Developer Tools mode (one-time, persists after reboot):

sudo DevToolsSecurity -enable

This tells macOS to be more lenient with policy verification for developer tool processes. It is the same setting Xcode enables automatically — safe for any developer machine.

4. If syspolicyd is already spinning:

sudo killall syspolicyd

5. Launch Codex.

The root cause (as others here have noted) is that Codex creates temp wrapper executables with random names in ~/.codex/tmp/arg0/, which carry a com.apple.provenance attribute that prevents Gatekeeper from caching its assessment. Every spawn triggers a full verification. DevToolsSecurity -enable reduces the impact of this loop significantly.

Still not a proper fix — that needs to come from OpenAI by using a fixed, signed path for these wrappers.

Adding the upstream trigger: this is state-dependent — driven by accumulated ~/.codex history, via the startup thread/rollout reconciliation

Confirming this on macOS 26.5.1 (25F80, Apple Silicon), Codex Desktop 26.616.32156 (build 4157), bundled CLI 0.142.0-alpha.1. The downstream mechanism here and in #25882/#19885/#17225 matches what I see exactly, but I was able to pin down what starts the spawn loop, which I haven't seen identified in any of these threads. Sharing in case it helps root-cause it.

Downstream (confirms existing reports). From a privileged capture while wedged, syspolicyd held 4,844 open read FDs to one file, /Applications/Codex.app/Contents/MacOS/Codex (same inode; FDs 18→4863, near-contiguous = a monotonic open-never-close leak), i.e. 99.3% of its FD table (4844/4878). Once saturated it fails every assessment with UNIX error exception: 24 / Failed to generate SecStaticCode … error: 100024 (EMFILE), and all app launches are denied system-wide. Code signing is valid (Developer ID OpenAI OpCo, LLC 2DC432GLL2); the "damaged app" dialogs are downstream of the wedged daemon. This is the same FD/EMFILE picture as the community thread's ~2,540 FDs.

Upstream trigger (new): it's the accumulated ~/.codex state, not a watchdog/Sparkle loop. I ran a 1 Hz recorder of syspolicyd's FD count to the Codex binary from a clean boot across controlled launches:

• Idle launch, no interaction: codex_fds goes 0 → ~1,300 in ~6 s. In the same ~4 s window the kernel logs ~750 distinct denied PIDs (ASP: Security policy would not allow process: <pid>, /Applications/Codex.app/Contents/MacOS/Codex), and the spawned binary named in the provenance errors is /Applications/Codex.app/Contents/Resources/codex. The storm-window syspolicyd/Codex trace logs are dominated by codex_rollout::state_db handling thread/list from client "Codex Desktop".
• Empty ~/.codex (only auth.json + config.toml + plugins seeded, no history): idle launch peaks at ~65 FDs — no storm. Same machine/OS/app/config.
• So the trigger scales with accumulated history. My ~/.codex had ~3,900 active threads in state_5.sqlite (+5,878 rollout .jsonl files) from months of heavy multi-agent use.

Where the leak happens. The denied spawns fail on Unable to apply provenance sandbox / Unable to initialize qtn_proc: 3. The FD leak tracks this failure path — at idle steady state, successful assessments reuse and close a single descriptor; it's the denied spawns that accumulate. (I couldn't capture the children's argv directly — they're denied at exec before they can log — so the precise "spawn a codex child per reconciled thread/rollout" step is inferred from the timing + the codex_rollout::state_db/thread/list dominance, not proven at the line level.)

What does NOT fix it (so the index isn't the whole story): pruning state_5.sqlite to the last week (515 threads) → still storms; to 100 threads → still storms and the table repopulates from the rollout files (100 → 285 in one launch); closing all 626 "open" thread_spawn_edges → still storms. The storm saturates well below 100 threads and isn't proportional to count. The only quiet config is ~no accumulated history — which is exactly why #26507's "rename ~/.codex" fix works.

Magnitude: ~900 FDs are retained per launch (one uncapped run settled at 917 and held), so the ~4,844 ceiling is reached cumulatively over ~5 launches — matching "reboot helps temporarily, recurs after continued use."

Likely fix area: whatever runs at app-server startup to reconcile/enumerate threads/rollouts (the codex_rollout::state_db / thread/list path) appears to launch a short-lived child per item, with no cap/backoff, and those children fail provenance/qtn_proc. Reusing a persistent worker (as suggested in #19885), capping/backing off on denial, and not re-deriving the full thread set from rollout files on every launch would all break the chain.

Recovery without reboot: as noted in the community thread, sudo killall syspolicyd clears the wedge immediately (launchd respawns it); launchctl kickstart -k system/com.apple.security.syspolicy is SIP-blocked. Neither prevents recurrence — only reducing accumulated history (or a fix here) does.

Happy to share the capture scripts / raw lsof+fs_usage+log artifacts if useful. Related: #25882, #19885, #18333, #17225, #26507.

**Follow-up: killall syspolicyd after boot doesn't just recover — it prevents recurrence; a reboot re-arms it**

Building on my earlier comment here. Several threads list sudo killall syspolicyd as a recovery; in testing today I found something more specific and more useful:

• Reboot recovers the wedge but RE-ARMS it. After a cold reboot, launching Codex reliably re-storms — syspolicyd's open FDs to /Applications/Codex.app/Contents/MacOS/Codex climb back into the thousands (peak ~2,200–2,500 in my runs), denials in the thousands. This is exactly why "reboot only fixes it temporarily."
• **sudo killall syspolicyd run once after the system has fully booted recovers AND disarms. On a warm (post-boot) system, after the killall the freshly-respawned daemon stays healthy: Codex runs, and can be quit and relaunched repeatedly**, without re-storming. syspolicyd RSS stayed flat (~90 MB) and Gatekeeper assessments stayed fast, even with Codex actively spawning helpers.

Interpretation: the leak-arming looks like a property of the boot-time syspolicyd — it appears to come up in a degraded state (possibly an early-boot init/dependency, or a SQLite-WAL / quarantine-subsystem timing issue), not a per-launch condition. A reboot hands you a fresh-but-armed boot-time daemon; a post-boot killall respawns it in a fully-ready environment, so it initializes cleanly and the spawns stop failing provenance/qtn_proc.

Practical workaround: after each reboot, run sudo killall syspolicyd once before using Codex. (launchctl kickstart of syspolicyd is SIP-blocked, so killall is the way.)

Caveat: this is one machine over a focused session (macOS 26.5.1, Codex 26.616.32156) — verified across several Codex relaunches, but not yet across days of heavy use. Would appreciate confirmation from others hitting this.

short-lived child per item

ooof that's gonna suck for anyone using jamf

Nothing working for me... Had to stop using codex altogether as it would use >200% CPU immediately and grow ram usage (the syspolicyd process) indefinetely. Found out the problem when i saw syspolicyd using over 35gb of ram ...

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.

Big +1, this makes the app unusable... trustd is at 99.9% all the time throttling my entire environment