Codex macOS app relaunches its own main binary in a tight loop, exhausting syspolicyd file descriptors and freezing all app launches system-wide

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

• #25243
• #25719
• #25703

Powered by Codex Action

Cross-referencing related reports of the same root cause: #25719 and #25243 (and the closed #25703). All describe Codex Desktop on macOS driving syspolicyd into a runaway state after launch.

This issue adds the underlying mechanism the others did not pin down: it is file-descriptor exhaustion of syspolicyd (default soft fd limit = 256), driven by the app re-posix_spawn-ing its own main binary tens of times per second in a no-backoff, no-cap loop. Once syspolicyd hits EMFILE (errno 24 / error: 100024), every Gatekeeper evaluation fails and no app on the machine can launch — i.e. a system-wide DoS, not just high CPU/RAM. Killing Codex stops it instantly; re-opening brings it back (verified 3×).

Happy to have this merged into whichever thread the maintainers prefer to track.

I can reproduce the same root cause on another machine, so I am closing my separate report (#26117) as a duplicate of this issue.

Additional environment:

macOS: 26.5 (25F71), arm64
Codex App: 26.527.60818
Codex main executable: /Applications/Codex.app/Contents/MacOS/Codex
spctl after reboot: accepted, Notarized Developer ID, OpenAI OpCo, LLC (2DC432GLL2)

Additional live fd evidence from a root launchd monitor sampling syspolicyd with lsof:

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
later live snapshot:         2026-06-03 17:07:37 syspolicyd_pid=489 total_fd=2575 codex_main_fd=2535 max_fd=2559
max observed:                total_fd=2576 codex_main_fd=2536 max_fd=2559

The corresponding lsof snapshot had 2,576 lines, with 2,535 descriptors pointing to the Codex main executable:

codex_fd_count=2535
min_codex_fd=17
max_codex_fd=2559

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

Recent logs on this machine also showed:

syspolicyd: UNIX error exception: 24
Failed to generate SecStaticCode ... error: 100024
failed to call driver: 0x3

This matches the fd-exhaustion mechanism described here. My report (#26117) has a little more local timing detail, but this issue is the better canonical tracker.

GitHub update for openai/codex #25882

Independent reproduction on a newer Codex Desktop and macOS build:

macOS: 26.5.1 (25F80), arm64
Codex Desktop: 26.601.21317 (3511)
Bundle: /Applications/Codex.app

This remains reproducible after reducing the suspected trigger surface:

• Spotlight indexing and searching are disabled for /, /System/Volumes/Data, and /System/Volumes/Preboot.
• Codex Computer Use has been isolated/disabled.
• The Codex Chrome operation extension is disabled in both Codex and Chrome, and no residual extension-host process is running.
• CodexBar is not running.
• The npm-distributed Codex CLI was removed.
• Codex.app was reinstalled multiple times; rebooting macOS and reinstalling only provided temporary or no relief.

Despite those changes, after leaving Codex Desktop running, the current live snapshot is:

syspolicyd elapsed: 13:36:56
syspolicyd CPU: 35.6%
syspolicyd RSS: 3,960,240 KB
syspolicyd total FDs: 33,284
FDs pointing to /Applications/Codex.app/Contents/MacOS/Codex: 33,245

codesign --verify --deep --strict /Applications/Codex.app succeeds. Raising maxfiles only delays the system-wide failure; it does not stop the leak.

Earlier severe snapshots on the same machine reached approximately:

syspolicyd total FDs: 67,854
FDs pointing to the Codex main executable: 67,820
syspolicyd RSS: up to approximately 20 GB

At that point, newly launched applications can bounce in the Dock and fail to open, while spctl begins returning:

Too many open files

Quitting Codex and running sudo killall syspolicyd restores normal application launching temporarily. Reopening Codex causes the leak to resume.

The Spotlight and optional-component isolation results suggest that neither Spotlight, Computer Use, the Chrome operation extension, CodexBar, nor the npm CLI is the sole root cause. The Chrome operation extension appeared to accelerate the leak when enabled, but the leak continues without it. The remaining common factor is Codex Desktop itself, its main-process lifecycle, or another bundled child/helper process repeatedly triggering Gatekeeper assessment.

I can provide additional sanitized lsof, sample, and Unified Log evidence if useful.

Additional local reproduction with two possibly-novel observations

Environment (matches Anarcadia's earlier comment in this thread):

• macOS: 26.5, Darwin Kernel 25.5.0, arm64
• Codex Desktop: 26.601.21317 (3511) — same build Anarcadia reported
• Bundle: /Applications/Codex.app

Symptom — partial self-recovery between spikes

1. spctl -a -vv /opt/homebrew/bin/mo (a Homebrew bash script) returned Too many open files on one snapshot.
2. Bash scripts launched at that moment received zsh: killed — SIGKILL during fork+execve, presumably because Gatekeeper evaluation via syspolicyd failed during dyld loading.
3. About 5 minutes later, the identical spctl call succeeded and returned a normal rejected (no usable signature) for the same path. No user action, no Codex quit.

This adds a data point that, on top of the monotonic leak previously described, syspolicyd appears to partially release fds over time at a rate below accumulation — producing intermittent spikes where the system briefly cannot launch apps, then recovers, then breaks again. Earlier comments treated the curve as strictly monotonic; on this machine it is sawtooth.

Possibly novel evidence — multiple embedded Chromium framework versions coexist as orphans

Current full Codex.app descendant snapshot (Codex Desktop running, idle, no user activity):

849   .../Codex Framework.framework/Versions/148.0.7778.179/Helpers/browser_crashpad_handler --monitor-self
851   .../Codex Framework.framework/Versions/148.0.7778.179/Helpers/browser_crashpad_handler --no-periodic-tasks
25703 /Applications/Codex.app/Contents/MacOS/Codex                    <- current main
25706 .../Versions/149.0.7827.54/Helpers/browser_crashpad_handler --monitor-self
25708 .../Versions/149.0.7827.54/Helpers/browser_crashpad_handler --no-periodic-tasks
25711 .../Versions/149.0.7827.54/Helpers/Codex (Service).app/... --type=gpu-process
25712 .../Versions/149.0.7827.54/Helpers/Codex (Service).app/... --type=utility (NetworkService)
25713 .../Versions/149.0.7827.54/Helpers/Codex (Service).app/... --type=utility (StorageService)
25766 /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
25846 .../Versions/149.0.7827.54/Helpers/Codex (Renderer).app/... --type=renderer
25847 .../Versions/149.0.7827.54/Helpers/Codex (Renderer).app/... --type=renderer
42820, 42822  Versions/148.0.7778.179/.../browser_crashpad_handler   <- another orphan pair
62899, 62901  Versions/148.0.7778.179/.../browser_crashpad_handler   <- yet another orphan pair

Six browser_crashpad_handler instances are running, split across two embedded Chromium framework versions (148.0.7778.179 and 149.0.7827.54). The 148-version helpers (PIDs 849, 851, 42820, 42822, 62899, 62901) all have PIDs lower than the current main Codex process (PID 25703), so they predate the current launch — they appear to be orphans from previous Codex launches that survived the parent's exit.

Hypothesis worth checking: each new launch of Codex.app, plus any auto-update of the embedded Codex Framework.framework/Versions/<chromium-version>/, triggers fresh Gatekeeper evaluation of the current bundle path. Older versions' crashpad helpers stay alive holding mach references to the older bundles — every Gatekeeper assessment caused by interaction with those orphans could pin an fd inside syspolicyd for the lifetime of the orphan helper. If that is correct, fd growth would correlate with frequency of embedded Chromium framework updates (which tracks upstream Chromium release cadence) more than with user activity.

This would also explain Anarcadia's observation that disabling Computer Use, the Chrome extension, CodexBar, and the npm CLI did not stop the leak: none of those interact with the embedded framework lifecycle, but framework auto-update still does.

Current syspolicyd state (no sudo here, so no fd count)

syspolicyd PID 488, uptime 2d 21h 16m, %CPU 11.9, RSS 362 MB
kern.num_files = 12259 / 184320  (6.6% global, leak is fully inside syspolicyd)

11.9% steady-state CPU on idle macOS for a signature-validation daemon is already abnormal; RSS 362 MB is well below Anarcadia's 3.9 GB / 20 GB but consistent with an earlier point on the same growth curve.

Workaround confirmed effective here

• osascript -e 'quit app "Codex"'
• sudo killall syspolicyd (launchd respawns instantly with a clean fd table)

App launches recover immediately. Reopening Codex starts the slow rebuild.

Happy to provide a sudo'd lsof -p $(pgrep syspolicyd) | grep Codex | wc -l snapshot, a sample syspolicyd 5 profile, or filtered Unified Log on request — particularly to test the "orphan framework helpers pin syspolicyd fds" hypothesis.

I can reproduce this on another Apple Silicon Mac, and the local evidence matches the file-descriptor / self-binary assessment pattern described here.

Environment:

• Hardware: MacBook Pro, Mac15,8, Apple M3 Max, 128 GB RAM
• macOS: 26.5 (25F71)
• Codex Desktop: 26.527.60818, build 3437
• App path: /Applications/Codex.app

Observed while Codex Desktop is open:

/usr/libexec/syspolicyd      ~46% to 110% CPU
/usr/libexec/trustd          ~24% to 36% CPU
/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled  ~13% to 20% CPU

The key matching signal is that syspolicyd has a large number of open file descriptors for Codex's own main binary:

sudo lsof -p $(pgrep -x syspolicyd | head -1) | awk '/\/Applications\/Codex.app\/Contents\/MacOS\/Codex/ {c++} END {print c+0}'

I observed:

2536

After restarting syspolicyd, it immediately reproduced again; a later check showed:

1714

spctl / code signing look normal, so this does not appear to be a broken local signature or damaged app bundle:

/Applications/Codex.app: accepted
source=Notarized Developer ID
Identifier=com.openai.codex
Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
Notarization Ticket=stapled
TeamIdentifier=2DC432GLL2
Runtime Version=26.5.0

Sampling syspolicyd also showed it spending time in the system policy / code-signing path, including com.apple.security.syspolicy.yara, SecStaticCodeCreateWithPath, SecKeyVerifySignature, sqlite policy DB access, and CFNetwork calls.

This is reproducible enough that simply restarting syspolicyd is only a temporary mitigation; it comes back while Codex Desktop stays open.

I can reproduce this on macOS with Codex Desktop 26.601.21317 build 3511.

Additional local evidence:

• syspolicyd accumulated tens of thousands of FDs pointing at the Codex main binary. One sampled state was 33341 total FDs, with 33336 entries matching /Applications/Codex.app/Contents/MacOS/Codex; earlier in the same session it reached ~70k.
• Restarting syspolicyd / taskgated / trustd / lsd temporarily restores normal app launching, but the FD count starts accumulating again while the same Codex Desktop session keeps running.
• Setting ~/.codex/config.toml to notify = [] is not enough for the currently running Desktop session. It only appears to take effect after fully quitting/restarting Codex Desktop or starting a new session.

Source-level observations from current main (16d02ec7 when checked):

• codex-rs/hooks/src/legacy_notify.rs implements legacy notify as spawn-and-forget: it calls command.spawn() and immediately returns. It does not wait, timeout, reap output, apply backoff, or use a single-flight/circuit breaker.
• codex-rs/hooks/src/engine/command_runner.rs has the newer managed hook runner behavior: wait_with_output(), timeout, and kill_on_drop(true). So legacy notify is much less bounded than the newer hook path.
• codex-rs/core/src/session/tests.rs explicitly asserts that notify is session-static during runtime config refresh. This matches the observed behavior where editing config.toml during a running Desktop session does not stop the issue.
• The public repo does not appear to contain the macOS Desktop/Electron shell or SkyComputerUseClient implementation, so the exact self-relaunch / Gatekeeper assessment loop likely lives outside the public source tree. The public Rust layer does show how notify can become a process-launch amplifier if Desktop wires it to the Computer Use helper.

Potential fixes suggested by this evidence:

• Avoid using legacy notify for Desktop/Computer Use integration, or route it through the managed hook runner with timeout/backoff/single-flight/circuit-breaker behavior.
• Preserve user-disabled Browser/Computer Use/Locked Use state and do not rewrite notify back to SkyComputerUseClient after the user disables it.
• In the macOS Desktop layer, avoid repeatedly launching the main app binary as a helper; use a dedicated signed/notarized helper or the packaged codex app-server binary, and add launch backoff/failure quarantine around any helper relaunch loop.

Current practical workaround here is: set notify = [], fully quit/restart Codex Desktop so the session-static config is reloaded, and avoid Desktop Computer Use/Browser/Locked Use until this is fixed. Restarting Apple security daemons is only temporary recovery, not a fix.

Still reproduces on Codex 26.601.21317 (build 3511) / macOS 26.5.1 (25F80) arm64 — not fixed in the current build, and it happens with Computer Use completely inactive (no automation running, the app just open in the background).

I captured the syspolicyd side while it was saturating. In a 15-second log show --last 15s --predicate 'process == "syspolicyd"' window:

• [com.apple.syspolicy.exec] Performing unconditional ticket check — ~3,300 times (~220/sec)
• [com.apple.syspolicy.exec] Recording cache miss for <private> — ~3,300 times
• CKTicketStore network reachability / cloudkit request cache info: <private>, max-age=N / ticket not available — hundreds

So every relaunch forces an uncached online notarization-ticket lookup (CloudKit / CKTicketStore) that always misses the cache and is never cached, and each one leaks a file descriptor. On a freshly-restarted syspolicyd the open handles on the Codex binary climb to ~2,540 and plateau (the fd ceiling) within ~15 seconds:

PHASE A (provenance present): t=0s 1152  t=15s 2542  t=30s 2541

Once syspolicyd is saturated the breakage is system-wide — every app launch fails the same way, not just one app (any app needing a Gatekeeper/notarization check hangs or is denied). The clearest crash signature I captured is NordVPN:

Library not loaded: @rpath/vinisFFI.framework/Versions/A/vinisFFI
Referenced from: /Applications/NordVPN.app/Contents/MacOS/NordVPN
Reason: ... '/Applications/NordVPN.app/Contents/Frameworks/vinisFFI.framework/Versions/A/vinisFFI'
(code signature ... not valid for use in process: library load denied by system policy)

i.e. a perfectly notarized app aborts (DYLD / SIGABRT at launch) because syspolicyd can no longer validate its bundled framework. Same failure family as #19166.

sudo killall syspolicyd recovers temporarily; the descriptors refill within minutes while Codex runs, and quitting Codex stops it. On this machine the trigger is the process-spawn frequency from the bundle (Contents/Resources/node_repl, Contents/Resources/codex, and npm exec MCP servers being re-spawned), independent of Computer Use.

Note com.apple.provenance on Codex.app cannot be used as a workaround: xattr -d com.apple.provenance returns success but the system re-stamps it immediately, and removing it did not change the leak rate.

Update: fixed in Codex 26.602.30954 (build 3575) — the build currently served from the official desktop URL.

After upgrading from 26.601.21317 → 26.602.30954 on the same machine (macOS 26.5.1 / 25F80, arm64), the syspolicyd storm is gone. Same 15-second log show --last 15s --predicate 'process == "syspolicyd"' window, Codex fully running:

| metric (15s window) | 26.601.21317 | 26.602.30954 |
|---|---|---|
| total syspolicyd log lines | ~42,800 | 622 |
| Performing unconditional ticket check | ~3,300 | 0 |
| Recording cache miss | ~3,300 | 0 |

Open file descriptors held by syspolicyd on the Codex binary stayed at 0 across 9 samples over ~3 minutes (the old build saturated to ~2,540 within 15s), and syspolicyd CPU stayed at 0–2% (was pegged at 84–128%). syspolicyd never needed a restart.

Download used (official desktop build): https://persistent.oaistatic.com/codex-app-prod/Codex.dmg

Update: fixed in Codex 26.602.30954 (build 3575) — the build currently served from the official desktop URL.

M1 Pro 16 inch, macOS version 26.5.1 25F80, same 602.30954 build, not fix yet, no lucky on this.

Duplicate of: https://github.com/openai/codex/issues/25243

In the latest Codex version 26.602.30954,
I have tested and confirmed that the issue has now been resolved.
(MacOS Version 26.5.1 [25F80])

Fix:

1. Update Codex.
2. Run the following command to restart syspolicyd, which had been compromised by the older version of Codex.

sudo killall syspolicyd trustd

I can confirm a partial fix, but not a full return to a healthy syspolicyd state on my machine.

Environment:

• Codex Desktop: 26.602.30954 (build 3575)
• After updating, I ran sudo killall syspolicyd trustd

1. The reported fixed behavior is partially true

After updating to 26.602.30954 and restarting syspolicyd / trustd, the original severe loop did stop initially.

Observed baseline after restart:

t0   Codex FD = 430
t30  Codex FD = 159
t60  Codex FD = 0
t120 Codex FD = 0
t180 Codex FD = 0
syspolicyd CPU = 0%
syspolicyd RSS ~= 136 MB
spctl Codex/Chrome/Calculator = accepted
Performing unconditional ticket check = 0
Recording cache miss = 0

So I agree that the latest build appears to fix the main old syspolicyd / Gatekeeper storm, at least immediately after killing the previously polluted security daemons.

2. However, syspolicyd still does not look healthy after continued use

With Computer Use disabled, the Chrome Codex operation plugin disabled, and CodexBar still running, I no longer see the catastrophic failure mode:

spctl Codex/Chrome/Calculator = accepted
Performing unconditional ticket check = 0
Recording cache miss = 0
Computer Use FD = 0
Chrome extension-host FD = 0

But syspolicyd still remains under abnormal pressure compared with the clean baseline:

syspolicyd RSS ~= 1.52 GB
total FD = 771 -> 1486
Codex FD = 731 -> 1446

This is far below the worst case, but also far above the healthy post-restart baseline where Codex FD dropped to 0 and RSS was around 136 MB.

My current interpretation: the app no longer breaks Gatekeeper assessment immediately, but syspolicyd can still remain in a semi-polluted / high-pressure state.

3. Computer Use and the Chrome operation plugin may amplify or re-trigger the pressure

When I re-enabled a broader Codex component set, including Computer Use, CodexBar, and the Chrome operation plugin, syspolicyd pressure increased sharply again:

syspolicyd total FD = 10663
Codex FD = 10659
CPU ~= 37.8%
RSS ~= 1.32 GB
spctl still accepted
Performing unconditional ticket check = 0
Recording cache miss = 0

In a later state where Chrome extension-host was absent but Computer Use was still running, I still saw:

syspolicyd total FD ~= 6095
Codex FD ~= 6087
CPU ~= 13%
RSS ~= 1.5 GB

After fully preventing Computer Use from launching and keeping the Chrome plugin disabled, pressure dropped back to the hundreds / low thousands range.

So my current conclusion is:

• The latest Codex build likely fixes the original unconditional-ticket-check / cache-miss storm.
• But syspolicyd may still remain abnormally loaded after prolonged Codex Desktop use.
• Computer Use, and possibly the Chrome operation plugin, appear to significantly amplify the FD pressure.
• I cannot yet prove Computer Use is the root cause of recurrence, but it is a strong suspect and deserves separate investigation.

I would be interested to know whether other users who report this as fixed also have Computer Use and the Chrome operation plugin enabled or disabled.

If you're still seeing this issue with 26.602.30954+, please use /feedback to upload logs and post the session ID here. Thanks!

I can confirm a partial fix, but not a full return to a healthy syspolicyd state on my machine. Environment: - Codex Desktop: 26.602.30954 (build 3575) - After updating, I ran sudo killall syspolicyd trustd ### 1. The reported fixed behavior is partially true After updating to 26.602.30954 and restarting syspolicyd / trustd, the original severe loop did stop initially. Observed baseline after restart: ``text t0 Codex FD = 430 t30 Codex FD = 159 t60 Codex FD = 0 t120 Codex FD = 0 t180 Codex FD = 0 syspolicyd CPU = 0% syspolicyd RSS ~= 136 MB spctl Codex/Chrome/Calculator = accepted Performing unconditional ticket check = 0 Recording cache miss = 0 ` So I agree that the latest build appears to fix the main old syspolicyd / Gatekeeper storm, at least immediately after killing the previously polluted security daemons. ### 2. However, syspolicyd still does not look healthy after continued use With Computer Use disabled, the Chrome Codex operation plugin disabled, and CodexBar still running, I no longer see the catastrophic failure mode: `text spctl Codex/Chrome/Calculator = accepted Performing unconditional ticket check = 0 Recording cache miss = 0 Computer Use FD = 0 Chrome extension-host FD = 0 ` But syspolicyd still remains under abnormal pressure compared with the clean baseline: `text syspolicyd RSS ~= 1.52 GB total FD = 771 -> 1486 Codex FD = 731 -> 1446 ` This is far below the worst case, but also far above the healthy post-restart baseline where Codex FD dropped to 0 and RSS was around 136 MB. My current interpretation: the app no longer breaks Gatekeeper assessment immediately, but syspolicyd can still remain in a semi-polluted / high-pressure state. ### 3. Computer Use and the Chrome operation plugin may amplify or re-trigger the pressure When I re-enabled a broader Codex component set, including Computer Use, CodexBar, and the Chrome operation plugin, syspolicyd pressure increased sharply again: `text syspolicyd total FD = 10663 Codex FD = 10659 CPU ~= 37.8% RSS ~= 1.32 GB spctl still accepted Performing unconditional ticket check = 0 Recording cache miss = 0 ` In a later state where Chrome extension-host was absent but Computer Use was still running, I still saw: `text syspolicyd total FD ~= 6095 Codex FD ~= 6087 CPU ~= 13% RSS ~= 1.5 GB ` After fully preventing Computer Use from launching and keeping the Chrome plugin disabled, pressure dropped back to the hundreds / low thousands range. So my current conclusion is: - The latest Codex build likely fixes the original unconditional-ticket-check / cache-miss storm. - But syspolicyd` may still remain abnormally loaded after prolonged Codex Desktop use. - Computer Use, and possibly the Chrome operation plugin, appear to significantly amplify the FD pressure. - I cannot yet prove Computer Use is the root cause of recurrence, but it is a strong suspect and deserves separate investigation. I would be interested to know whether other users who report this as fixed also have Computer Use and the Chrome operation plugin enabled or disabled.

It appears to be the issue of computer use on my side, after disable it in version 26.602.30954 syspolicyd didn't spawn codex fd, but enable it will give a constantly codex fd level at around 3000 at start time and around 10000 as using. spctl still working in test but it's heating the laptop very quickly.

Confirmed the original storm is fixed on 26.602.30954 (build 3575), Darwin 25.1.0 arm64 — with Computer Use and the browser plugin NOT enabled during the test.

Codex app running for ~2.5 hours (Computer Use off, no browser/Chrome plugin active):

• MacOS/Codex Gatekeeper denials: 0 (was ~31,273 per 30 min before the fix)
• syspolicyd EMFILE / "too many open files" / mid-eval errors: 0
• syspolicyd idle the whole window (CPU ~0%, RSS stable, no relevant log entries)

So this build resolves the original unconditional-ticket-check / re-exec storm in my setup. Important caveat: I had Computer Use and the Chrome/browser plugin disabled during this window, so this does not cover the residual syspolicyd fd pressure that @Anarcadia and @ZHDI-1 report when Computer Use is enabled on the same build.

Verified with:

log show --predicate 'eventMessage CONTAINS "would not allow" AND eventMessage CONTAINS "Codex.app"' --last 2h | grep -c Codex.app
# -> 0

@hcandy Yes, but I wouldn't call it a _fix_. Just a confirmation that Computer Use _is_ the root-cause.

Update after installing the newer build and testing the two remaining variables separately.

Environment:

macOS: 26.5.1 (25F80), arm64
CPU: Apple M5 Pro
Codex Desktop: 26.602.40724 (build 3593)
Signature timestamp: Jun 6, 2026 00:44

Before these tests, I quit/restarted Codex and ran:

sudo killall syspolicyd trustd

Comparison with previous build / previous state

On the previous build/state I last observed, even with Computer Use and the Chrome operation plugin disabled, syspolicyd still looked semi-polluted:

syspolicyd RSS ~= 1.52 GB
Codex FD ~= 1446
spctl Codex/Chrome/Calculator = accepted
Performing unconditional ticket check = 0
Recording cache miss = 0

So the catastrophic failure was gone, but the daemon still did not look healthy.

Current build: Computer Use ON, Chrome plugin OFF

With Computer Use enabled and running, but the Chrome operation plugin disabled:

SkyComputerUseService: running
SkyComputerUseClient mcp: running
Chrome extension-host: not running
spctl Codex/Chrome/Calculator = accepted

Observed syspolicyd behavior:

t+00:55  RSS ~= 324 MB, total FD = 1712, Codex FD = 1672
t+03:32  RSS ~= 326 MB, total FD = 40,   Codex FD = 0
t+05:41  RSS ~= 328 MB, total FD = 132,  Codex FD = 92

Old failure signatures remained absent:

Performing unconditional ticket check = 0
Recording cache miss = 0
Too many open files / UNIX error 24 = 0

This is a major improvement compared with the previous semi-polluted state. Computer Use no longer immediately reproduces the old failure on my machine.

Current build: Computer Use ON, Chrome plugin ON

Then I enabled the Chrome operation plugin without restarting Codex or killing syspolicyd again.

SkyComputerUseService: running
SkyComputerUseClient mcp: running
Chrome extension-host: running
spctl Codex/Chrome/Calculator = accepted

Before enabling the Chrome plugin, the nearby baseline was:

RSS ~= 328 MB
total FD = 132
Codex FD = 92

After enabling the Chrome plugin:

t+00:19  RSS ~= 561 MB, total FD = 2549, Codex FD = 2509
t+02:34  RSS ~= 553 MB, total FD = 134,  Codex FD = 95
t+06:23  RSS ~= 556 MB, total FD = 334,  Codex FD = 294

Again, the old failure signatures remained absent:

Performing unconditional ticket check = 0
Recording cache miss = 0
Too many open files / UNIX error 24 = 0

My current read: on 26.602.40724, this is broadly fixed on my machine in the practical sense. The FD spike still happens during startup / plugin activation, and the Chrome plugin clearly raises the syspolicyd RSS plateau, but the FDs now get released instead of continuously accumulating into the previous failure mode.

I do not know whether the remaining RSS level is expected or abnormal, so I will leave that for the Codex team to judge. I am resuming normal daily use, including Computer Use. If I see the previous severe app-launch / Gatekeeper failure again, I will submit /feedback logs and post the session ID here.

Confirming this is still reproducible on the latest build with Computer Use enabled, and adding a fresh data point.

Environment

• Codex Desktop 26.602.71036 (build 3685) — i.e. newer than the build (3575 / 26.602.30954) reported as fixing the original re-exec storm
• macOS 26.5.1 (25F80), Apple M4 Max (Mac16,5), arm64
• Computer Use + browser/Chrome plugin enabled

Symptoms

• With Codex closed, syspolicyd/trustd sit at ~0% CPU. Within seconds of Codex running, syspolicyd + trustd climb to ~110–115% combined and stay there.
• Kernel log repeatedly shows: (AppleSystemPolicy) ASP: Security policy would not allow process: <pid>, /Applications/Codex.app/Contents/MacOS/Codex
• ps shows /Applications/Codex.app/Contents/MacOS/Codex and its helpers being (re)spawned continuously.

Confirmation of the fd-exhaustion mechanism described here
While Codex was running, a plain Gatekeeper assessment failed with EMFILE:

$ spctl -a -vvv -t exec /Applications/Codex.app
/Applications/Codex.app: Too many open files

…even though the bundle itself is correctly signed and unquarantined:

$ codesign -v --verbose=2 /Applications/Codex.app
/Applications/Codex.app: valid on disk
/Applications/Codex.app: satisfies its Designated Requirement

So syspolicyd is hitting its fd limit system-wide, not just burning CPU — matching the EMFILE/DoS analysis in this issue.

Workaround

• Quitting Codex returns syspolicyd/trustd to idle.
• sudo killall syspolicyd trustd clears the exhausted state without quitting Codex (temporarily).

This appears to be the residual Computer-Use path noted in #25719 / #25243: the build that fixed the unconditional re-exec storm does not cover the loop when Computer Use (and the browser plugin) are enabled. Would appreciate a fix that keeps Computer Use usable without the syspolicyd fd exhaustion.

I'm also seeing this _without_ computer use enabled. It seems to happen if you run a codex server anywhere (ssh into a docker container in my case). The workaround also does not work for me -- it instantly starts hammering the cpu syspolicyd and trustd as soon as codex desktop is doing any work.

Closing as a duplicate of #25243.

Yesterday, while using Codex CLI for an Xcode-related coding project, I used /app to migrate the conversation from the CLI to the app. After that, I started seeing a similar issue to yours: whenever I opened the app, syspolicyd would spike dramatically.

I removed that project from the app and deleted the related conversations, and since then the issue hasn’t happened again. Hope this helps.

I have exactly the same issue. I stopped using the app Some weeks ago I tried today again, and it crashes my system. I can't use the Codex app. Does anyone have a solution?