Codex Desktop 26.609.41114 repeatedly exhausts syspolicyd and cannot relaunch until reboot
What version of the Codex App are you using?
Codex Desktop 26.609.41114 (CFBundleVersion 3888)
Code signing details:
Identifier=com.openai.codex
CDHash=f669521b379f32fe57c858c7d806d14cb30d721f
Timestamp=Jun 13, 2026 at 6:54:30 AM
TeamIdentifier=2DC432GLL2
Runtime Version=26.2.0
Sealed Resources version=2 rules=13 files=7929What subscription do you have?
Not relevant to this local macOS app startup / system policy issue.
What platform is your computer?
macOS 26.5.1 (25F80)
Darwin 25.5.0 RELEASE_ARM64_T6050 arm64
Apple SiliconWhat issue are you seeing?
Codex Desktop 26.609.41114 repeatedly drives macOS syspolicyd into a high CPU / high memory / file-descriptor growth loop. Once this happens, Gatekeeper assessment starts failing globally, and other apps such as Typora cannot be launched until the machine is rebooted.
This looks related to existing syspolicyd / Too many open files / code_sign_clone reports, but I am opening a separate issue because my current reproduction has a specific loop:
- Reboot macOS.
- Launch Codex Desktop.
syspolicydCPU and FD count grow rapidly.- Quit Codex Desktop:
syspolicydCPU/FD growth stops. - Try to launch Codex Desktop again: it fails to open.
- Reboot macOS: Codex Desktop opens again, then the same
syspolicydrunaway loop starts again.
During the failure, spctl fails for unrelated apps:
/Applications/Typora.app: Too many open files
/Applications/Codex.app: Too many open filesAfter restarting syspolicyd, spctl temporarily recovers:
/Applications/Typora.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Abner Lee (9HWK5273G4)
/Applications/Codex.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)But while Codex Desktop continues running, syspolicyd starts growing again.
What steps can reproduce the bug?
On this machine:
- Reboot macOS.
- Open
/Applications/Codex.app. - Observe
syspolicyd:
ps -p "$(pgrep -x syspolicyd)" -o pid,%cpu,%mem,etime,command
sudo lsof -n -p "$(pgrep -x syspolicyd)" | wc -l
sudo lsof -n -p "$(pgrep -x syspolicyd)" \
| awk 'NR>1 {name=$9; for(i=10;i<=NF;i++) name=name " " $i; c[name]++} END{for(n in c) print c[n], n}' \
| sort -nr | headObserved results:
PID %CPU %MEM ELAPSED COMMAND
273 114.5 0.8 04:59 /usr/libexec/syspolicyd
161987 /Applications/Codex.app/Contents/MacOS/CodexIn a separate run, after restarting syspolicyd, the FD count quickly grew again while Codex Desktop was still running:
19:27:38 syspolicyd 127.3% CPU 31283 open files
19:27:49 syspolicyd 184.9% CPU 43360 open files
19:28:00 syspolicyd 200.2% CPU 58374 open files
19:28:14 syspolicyd 204.5% CPU 76565 open files
19:28:31 syspolicyd 208.9% CPU 88692 open filesThe open files are overwhelmingly the Codex main executable:
111533 /Applications/Codex.app/Contents/MacOS/Codexsample syspolicyd shows work concentrated in the macOS system policy / YARA / code-signing path:
Dispatch Thread Soft Limit: 90 reached
DispatchQueue_176: com.apple.security.syspolicy.yara
SecStaticCodeCreateWithPath
Security::CodeSigning::DiskRep::bestGuess
Security::CodeSigning::SingleDiskRep::fd()
Security::UnixPlusPlus::FileDesc::openI also see a temporary Codex code-sign clone directory while the problem is happening:
/var/folders/.../X/com.openai.codex.code_sign_clone
1.2G
/var/folders/.../X/com.openai.codex.code_sign_clone/code_sign_clone.<random>/Codex.app.bundle
1.2GThis directory contains a full Codex.app.bundle, including:
Contents/_CodeSignature
Contents/MacOS
Contents/Resources
Contents/Frameworks
Contents/embedded.provisionprofile
Contents/Info.plistWhat is the expected behavior?
Codex Desktop should not repeatedly trigger macOS syspolicyd / Gatekeeper / XProtect / YARA assessment of its own main executable in a way that causes CPU, memory, and FD count to grow without bound.
Quitting and relaunching Codex Desktop should not require rebooting macOS.
Unrelated apps should not fail Gatekeeper assessment with Too many open files.
Additional information
This began after the Codex Desktop app updated to 26.609.41114 on June 13, 2026. I initially noticed it after running brew update / brew upgrade, but local evidence points to the Codex Desktop app rather than the Homebrew CLI codex cask:
- Homebrew
codexcask is the terminal binary (0.139.0) under/opt/homebrew/bin/codex. - The runaway
syspolicydFD aggregation points at/Applications/Codex.app/Contents/MacOS/Codex. /Applications/Codex.appis signed and notarized.
Related issues I found:
- openai/codex#27662
- openai/codex#25719
- openai/codex#27536
- openai/codex#25243
- openai/codex#26341
- openai/codex#16767
I am opening this separately because the specific behavior here is:
26.609.41114- quitting Codex Desktop stops
syspolicydCPU/FD growth - relaunching Codex Desktop fails until reboot
- reboot allows one launch, then the runaway loop returns
code_sign_cloneappears during the failure
12 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional data point from another macOS 26.5.1 machine, with a slightly different user-visible failure mode: the Codex/syspolicyd FD buildup caused an unrelated signed Electron app (Claude Desktop) to fail at dyld library validation.
Environment
User-visible symptom
Launching Claude Desktop repeatedly crashed immediately. The Claude crash report showed dyld refusing to load its bundled Electron Framework:
Claude itself did not appear corrupt:
Realtime syspolicyd evidence during failed Claude launch
While launching Claude in the bad state, a realtime log stream from
syspolicydshowed EMFILE/YARA failures followed by malware rejection. Representative lines:This matches the pattern in this issue: system policy assessment fails because
syspolicydis unhealthy, then unrelated apps are rejected.Not global FD exhaustion
At the same time, the system-wide file table was not close to full:
Evidence pointing at Codex executable handles inside syspolicyd
With root privileges,
lsofonsyspolicydshowed almost all open descriptors pointing to the Codex app main executable:Total descriptors observed in that sample were about 2574, with 2537 of them being
/Applications/Codex.app/Contents/MacOS/Codex.Behavior after restarting syspolicyd
launchctl kickstart -k system/com.apple.security.syspolicywas blocked by SIP:But
sudo killall syspolicydlet launchd restart it and immediately fixed Claude launch. After that:I then measured
syspolicydagain. Immediately after restart:During continued Codex desktop activity and diagnostic commands from inside the Codex app, the count climbed again:
As a small control, running
/bin/true20 times did not change the Codex fd count insyspolicyd:So the growth does not appear to be caused by arbitrary subprocess launches alone. It appears tied to Codex Desktop / this Codex session repeatedly causing macOS policy assessment of
/Applications/Codex.app/Contents/MacOS/Codex.Why this may help narrow the bug
This data point shows the same Codex fd accumulation as the main issue, but with a downstream failure in an unrelated signed app:
syspolicydaccumulates thousands of duplicate read descriptors for/Applications/Codex.app/Contents/MacOS/Codex.syspolicydhits EMFILE while hashing/scanning.library load denied by system policy, causing the unrelated app to crash.I am intentionally not attaching the full Codex session transcript or raw process dumps because they can contain local paths, command arguments, and environment values. The excerpts above are sanitized except for public app bundle paths and version/build identifiers.
Additional data point from another macOS 26.5.1 Apple Silicon machine. This looks like the same macOS policy / signing /
syspolicydfailure class described in this issue, but in my case it reproduces from a fresh official DMG install and the first visible failure is AMFI rejecting the main Codex executable.Environment
Serial number, hardware UUID, and UDID are intentionally omitted.
DMG and signing checks
The DMG itself verifies as valid:
After copying
Codex.appto/Applications, the app appears valid to the usual signing/Gatekeeper checks:Launch failure
Launching the app fails:
Unified logs show AMFI rejecting the main executable:
Provisioning / entitlement mismatch
The embedded provisioning profile contains only:
But the app signature declares additional restricted entitlements, including:
So although
codesign/spctlaccept the bundle, AMFI rejects it at process launch because the restricted entitlements do not appear to be covered by the embedded provisioning profile.As a local diagnostic only, I tried ad-hoc re-signing the copied
/Applications/Codex.app. That got past the initial AMFI rejection, but the app then crashed because the main process and bundled framework signatures no longer matched:This points away from quarantine or a local drag/install mistake and toward the same signing/provisioning/system-policy layer discussed in this issue.
syspolicydhandle growthOne more local observation from the same machine: while Codex Desktop GUI was present/running,
syspolicydkept accumulating duplicate file descriptors for the Codex main executable.Observed handle growth:
This matches the behavior described in this issue: Codex Desktop appears to continuously drag macOS system policy / security validation through repeated opens of its own main executable. I am stopping/removing the GUI app locally for now and keeping only the CLI to avoid further impact on other signed apps.
<img width="1024" height="542" alt="Image" src="https://github.com/user-attachments/assets/9f00e573-7a6a-4152-ad1d-914e66f66783" />
Gemini suggested that I execute this command to debug the issue:
Here is the log output I captured:
Gemini analyzed these logs and indicated that there were two high-frequency operation conflicts triggering macOS security mechanisms:
syspolicydwas repeatedly performingopen,fstat64, andreadoperations on/Applications/Codex.app/Contents/Info.plist, likely due to signature verification issues.gitprocess was frequently readingSDKSettings.plistfiles, which may be caused by outdated or missing SDK configurations in my project.I decided to verify this by checking for updates in the Codex app. A dialog appeared asking me to update or update & restart. After I clicked the "Update & Restart" button, the CPU usage dropped immediately.
<img width="1024" height="542" alt="Image" src="https://github.com/user-attachments/assets/664da212-c170-402e-9e73-beae475793ae" />
now this my codex app version:
Version 26.609.71144 • Released Jun 16, 2026
same issue on 26.609.71450.
syspolicyd eat CPU. also after small time (10-20 min) new processes can't start (just can't open terminal for example). only reboot helps. if i run codex after reboot - all will broke again. so now i can't use codex at all.
macos 26.4 (25E246)
M1 Max
I am facing the Same issue, codex Version 26.609.71450
OS : 26.5.1 (25F80)
Same issue for here. Started happening June 11th for me. Stopped using until today to see if there was an update via OAI.
Today tried to update today and failed then cleared system cache and updated to 26.611.62324 (successfully) but met with same results as June 11:
Codex 26.611.62324 / bundle 4028 on macOS
codesign intermittently fails with invalid signature spctl reports "Too many open files" or "bundle format unrecognized" Launching Codex drives Codex >100% CPU, syspolicyd ~60%, trustd ~45%
Fans run hot, system super slow.
Unusable.
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).
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.
Same here!
Adding a related reproduction on a newer Codex Desktop build. This is similar to the
.git/workspace-trigger data point above, but in this case the trigger was a broken.gitfile containing an absolutegitdir:pointer synced from another Mac.Environment
Trigger
The workspace had a
.gitfile that contained an absolute gitdir pointer from another machine:On this Mac, that target path did not exist. Any Git operation in the workspace failed immediately:
This appears to happen naturally if a workspace is synced via iCloud Drive but its
--separate-git-dirtarget is local to another Mac.Observed behavior
With Codex Desktop open on that workspace, the Mac entered the same SystemPolicy failure class described in this issue:
syspolicydandtrustdclimbed to roughly ~50% CPU each.curl, ping, DNS) were fast, so this was not a network issue.Unified log count while bad:
Representative log pattern:
A privileged short
fs_usage -w -f execsample showed Codex repeatedly spawning Git/CLT-related processes from the workspace, including repeated executions of:Mitigation that stopped the storm
.gitpointer aside.git init --separate-git-dir=....After that:
And the SystemPolicy storm dropped sharply:
Chrome then launched normally again and loaded normal sites quickly.
Why this seems useful
This suggests one trigger path is not only Computer Use / code-sign clone / app attestation. A bad Git workspace state can also amplify the issue if Codex Desktop repeatedly probes Git without enough backoff.
In this repro, the root local condition was specifically:
Suggested Codex-side mitigation:
.gitgitdir:target once and mark Git unavailable/degraded for that workspace.git/xcode-selectprocess launch loops from the app/sidebar/review-summary path.Separate note: I also saw lower-rate
trustdwarnings mentioning2DC432GLL2.com.openai.sky.CUAService, but the high-rateviolates validation category policystorm correlated with the broken Git pointer and stopped after the Git metadata was repaired.I made 5 different .git and then test them out by copying .git to a workspace root directory.
A,B,C,D will trigger the problem. E won't.
D is the same scenario as @hgupt3 tried.