macOS Codex relaunch loop exhausts syspolicyd file descriptors and blocks app launches

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.527.31326 (3390)

What subscription do you have?

Pro

What platform is your computer?

macOS

What issue are you seeing?

syspolicyd is seeing one /Applications/Codex.app/Contents/MacOS/Codex process opening every 1 second, and the entire system freezes up after a little while, nothing opens with Too many files opened errors. I've tried killing every codex process, killing syspolicyd, rebooting etc, it starts to spam syspolicyd the moment I launch Codex.app

/
/usr/libexec/syspolicyd
/usr/lib/dyld
/Library/Preferences/Logging/.plist-cache.1EfNczv9
/private/var/db/SystemPolicyConfiguration/Tickets-shm
/private/var/db/analyticsd/events.allowlist
/private/var/db/timezone/tz/2026b.1.0/icutz/icutz44l.dat
/private/var/db/SystemPolicyConfiguration/KextPolicy-shm
/usr/share/icu/icudt78l.dat
/private/var/db/SystemPolicyConfiguration/ExecPolicy-shm
/System/Library/Frameworks/Security.framework/Versions/A/PlugIns/csparser.bundle/Contents/MacOS/csparser
/private/var/db/mds/messages/se_SecurityMessages
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/Resources/Localizable.loctable
/System/Library/Frameworks/CFNetwork.framework/Versions/A/Resources/DafsaData.bin
/dev/null
/dev/null
/dev/null
/private/var/db/SystemPolicyConfiguration/Tickets
/private/var/db/SystemPolicyConfiguration/Tickets-wal
/private/var/db/SystemPolicyConfiguration/Tickets-shm
[ctl com.apple.netsrc id 7 unit 63]
/private/var/db/SystemPolicyConfiguration/KextPolicy
/private/var/db/SystemPolicyConfiguration/KextPolicy-wal
/private/var/db/SystemPolicyConfiguration/KextPolicy-shm
/private/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gk.db
/private/var/db/SystemPolicyConfiguration/ExecPolicy
/private/var/db/SystemPolicyConfiguration/ExecPolicy-wal
/private/var/db/SystemPolicyConfiguration/ExecPolicy-shm
192.168.1.28:53283->17.248.213.70:https
/private/var/db/SystemPolicyConfiguration/XProtect.bundle/Contents/Resources/gk.db
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex

... **several hundreds more**

/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/MacOS/Codex
/Users/fahad/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
/Applications/Codex.app/Contents/MacOS/Codex

What steps can reproduce the bug?

Launch Codex

What is the expected behavior?

No response

Additional information

No response

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

Codex Desktop v26.527.30818 sustained main-process CPU burn after update #25159

Powered by Codex Action

If I turn off Locked use under settings, this stops happening. Actually it's the Computer Use plugin - if I turn this off, it stops.

It seems Computer Use gets re-added the moment you launch Codex. My entire mac is unusable, no other app or script works when I launch Codex. I've downgraded to Version 26.519.81530 (3178) and this works perfectly.

Update: Version 26.519.81530 (3178) (previous update) fixes this, as well as the excessive CPU usage issues for me. I don't see any new entry show up in syspolicyd

I continue to see this in Version 26.602.30954 • Released Jun 4, 2026 - no difference, 26.519.81530 is the only working version.

@etraut-openai

@etraut-openai This one's making it impossible to use Codex. Every single person I know (on codex) is affected. Numerous other reports, too. Please can we have this urgently looked into?

I've encountered this issue as well

@guidedways

@guidedways, it looks like a fix for this was attempted in 26.602.30954, but it sounds like it may not have completely fixed the problem (see this analysis). I'll raise the issue with the team.

Thank you so much!

I should add - I wouldn't even call this a partial fix, this was a temporary fix for the original version (from last week) that started behaving this way. That version behaved the same way - syspolicyd temporarily throttled or held back after a force-quit, before it went into a frenzy again. The only thing that truly helped was turning off Computer Use but recently it seems Computer Use gets forcefully added back even if it's turned off.

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

I continue to see this in Version 26.602.30954 • Released Jun 4, 2026 - no difference, 26.519.81530 is the only working version.

I am still, I downgraded the moment I saw the syspolicyd storm. I was worried that background tasks and scripts might start to fail. I’ll take a look at it soon and report back, thanks 😅

@etraut-openai

Just saw the following in the middle of work! But we cannot update as the issue isn't resolved.

@etraut-openai is this still an issue the team is actively looking into? It seems newer updates aren't trying to address this at all

For folks still trying different workarounds: I documented my local investigation and mitigation here: #25243 (comment)

Thank you! This finally worked for me! I'm at sysprofiled 0% !!!!

For folks still trying different workarounds: I documented my local investigation and mitigation here: #25243 (comment)

This didn't work for me. sudo lsof -c syspolicyd | wc -l shows around 2400 items right after startup :(

@andrea-sdl

@andrea-sdl ask codex to look at #25243 (comment) and fix the issue for you. It found 27GB worth of items on my mac, cleaned up the path etc and updated ~/.zhrc and it's working beautifully now.

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.

Superseded/correction: please do not treat this branch as a fix for this issue.

Later local triage on the same machine found the actual trigger: a malformed trusted workspace root. ~/.codex/config.toml had a trusted project entry for /Users/admin, and /Users/admin/.git was a broken git shell containing only gk/config; git -C /Users/admin rev-parse --git-dir --is-inside-work-tree failed with fatal: not a git repository.

Moving that broken .git directory to Trash stopped the storm locally. After a short settle period, the 15s syspolicyd window returned 0 rows for:

failed to call driver
UNIX error exception
SecTrustCopyAppleTrustAnchors
Failed to generate SecStaticCode

The /bin/ps branch may still remove a small PATH-resolution amplifier in app-server code, but it was not the root cause of my reproduction and should not be cherry-picked as the workaround for this issue.

Withdrawn / superseded.

Please do not cherry-pick the branch above as a fix for this issue. Later local evidence on the same machine found the real trigger to be a malformed trusted workspace root: ~/.codex/config.toml trusted /Users/admin, and /Users/admin/.git was a broken git shell. Moving that broken .git to Trash stopped the syspolicyd storm locally.

The branch may still be a narrow hardening improvement for a PATH/ps amplifier, but it is not the root-cause workaround for this report.

@jamguoxiaoqi

Confirming @jamguoxiaoqi's finding — a corrupted .git folder was the trigger for me too.

Big thanks to @jamguoxiaoqi for spotting this. On my machine (Codex 26.616.71553, macOS) I had the exact same runaway syspolicyd behavior, and a broken .git directory turned out to be the culprit.

The culprit: the root of my workspace had a gutted .git directory — only description and info/ were left, with no HEAD, config, objects/ or refs/. git status inside it just returned fatal: not a git repository. So it looked like a repo to a directory scan, but was actually a dead shell. (My 11 real sub-project repos were all fine — only this top-level one was broken.)

Before (with the broken .git):

syspolicyd CPU pinned at ~120–170%
Codex main-process file descriptors climbing without bound (matching the 227 → 2535 growth others reported)
Eventually "Too many open files" across the whole system

After (removed the broken .git):

syspolicyd CPU steady at 0.0% over repeated sampling
Codex main-process FDs flat at the ~237 baseline, no growth
System back to normal

Fix that worked for me — find the dead .git shells and remove them:

find . -maxdepth 4 -name .git \( -type d -o -type f \) | while read g; do
  if [ -d "$g" ] && { [ ! -f "$g/HEAD" ] || [ ! -e "$g/config" ] || [ ! -d "$g/objects" ]; }; then
    echo "BROKEN: $g"
  fi
done
# then, after confirming it has no recoverable history:
rm -rf path/to/broken/.git

To be clear, this is a workaround, not a real fix — Codex still shouldn't melt syspolicyd just because a directory contains a malformed .git. A backoff / safe-mode on repeated signature re-evaluation (as suggested above) still seems like the right long-term fix. But for anyone stuck right now, checking for a corrupted .git is well worth it.

@jamguoxiaoqi

Correction / final local result from the same machine: the Desktop sampler ps evidence below was real, but it was not the root cause of my reproduction.

The root trigger turned out to be a malformed trusted workspace root, matching the broken-.git reports from @jamguoxiaoqi and @goclaude:

~/.codex/config.toml had [projects."/Users/admin"] trust_level = "trusted".
/Users/admin/.git existed but was not a valid git repository. It contained only:

/Users/admin/.git
/Users/admin/.git/gk
/Users/admin/.git/gk/config

git -C /Users/admin rev-parse --git-dir --is-inside-work-tree returned:

fatal: not a git repository (or any of the parent directories): .git

Temporary workaround that fixed this machine:

/usr/bin/trash /Users/admin/.git

Validation after moving the broken .git to Trash:

/Users/admin/.git absent
git ok /Users/admin/code/ads_public/server_setup
git ok /Users/admin/code/notes
git ok /Users/admin/code/ads_public

syspolicyd_last15s
0    failed to call driver
0    UNIX error exception
0    SecTrustCopyAppleTrustAnchors
0    Failed to generate SecStaticCode

node_repl was already disabled on this machine via CODEX_NODE_REPL_PATH=/usr/bin/false, so that was not sufficient by itself. The useful local order now seems to be:

Inspect trusted project roots in ~/.codex/config.toml.
For each trusted root, check whether $root/.git exists and whether git -C "$root" rev-parse --git-dir --is-inside-work-tree succeeds.
Move malformed .git shells to Trash after confirming they are not real repositories.
Re-check syspolicyd logs over a short window.

The earlier Desktop sampler / repeated ps observation should be treated as an amplifier or follow-up hardening area, not as the primary root cause for this local reproduction.

Final correction from my local reproduction: the workaround that actually stopped the storm was removing a malformed .git directory from a trusted workspace root.

What was wrong locally:

[projects."/Users/admin"]
trust_level = "trusted"

but /Users/admin/.git was not a valid git repo:

/Users/admin/.git
/Users/admin/.git/gk
/Users/admin/.git/gk/config
fatal: not a git repository (or any of the parent directories): .git

Temporary workaround:

/usr/bin/trash /Users/admin/.git

After that, the next 15s syspolicyd window went to zero for the storm signatures:

0    failed to call driver
0    UNIX error exception
0    SecTrustCopyAppleTrustAnchors
0    Failed to generate SecStaticCode

So for anyone still seeing this: before chasing node_repl, Computer Use, PATH, or the Desktop sampler, first inspect the trusted project roots in ~/.codex/config.toml and remove malformed .git shells after confirming they are not real repositories.

Adding a temporary mitigation that has been working for my local machine. This is not a fix for the Codex/syspolicyd issue; it just keeps macOS usable while waiting for a real fix.

Environment where I reproduced this:

Machine: MacBook Pro M3 Pro, arm64
Codex Desktop: 26.616.81150
Codex CLI: 0.142.0
Symptom: syspolicyd CPU/RSS grows, then spctl and app launches fail with "Too many open files".

Local checks showed the usual pattern:

spctl -a -t exec -vv /bin/ls
# /bin/ls: Too many open files

spctl -a -vv /System/Applications/Calculator.app
# /System/Applications/Calculator.app: Too many open files

codesign --verify --deep --strict --verbose=2 /System/Applications/Calculator.app
# valid on disk; satisfies its Designated Requirement

So I added a small launchd monitor that samples syspolicyd every 5 minutes, logs CPU, and optionally restarts syspolicyd when it crosses a threshold. In my current setup:

CPU_THRESHOLD=25
INTERVAL_SECONDS=300
AUTO_RECOVER=1
RECOVERY_COOLDOWN_SECONDS=900

The script logs entries like:

2026-06-25 16:26:38 syspolicyd_cpu=31.0%
2026-06-25 16:26:38 threshold_exceeded cpu=31.0% threshold=25%
2026-06-25 16:26:38 auto_recover_attempt cpu=31.0% command='sudo -n /usr/bin/killall syspolicyd'
2026-06-25 16:29:46 auto_recover_success cpu=86.0%

For launchd auto-recovery to work, I had to allow only this one passwordless sudo command:

<username> ALL=(root) NOPASSWD: /usr/bin/killall syspolicyd

The monitor itself runs as a user LaunchAgent and only executes:

sudo -n /usr/bin/killall syspolicyd

when syspolicyd exceeds the CPU threshold and the cooldown has elapsed. This has been enough to prevent the system from getting stuck in the state where unrelated apps fail to launch. Again: this is a workaround only; Codex should not be driving syspolicyd into this condition in the first place.

@jamguoxiaoqi

Confirming @jamguoxiaoqi's finding — this fixed the same syspolicyd storm for me on macOS (Codex 26.616.x).

My trusted workspace ~/Documents/codex had a stray broken .git directory (only objects/pack/, no HEAD/config). The real git repo intentionally lives in .git.nosync for iCloud. After moving the broken .git out of the workspace, syspolicyd/trustd CPU dropped back to normal and Codex became usable again.

Thank you for posting this — it was the breakthrough after trying many other workarounds.

Adding another anonymized data point from an affected macOS machine.

Environment:

macOS: 26.5.1 (25F80), Apple Silicon
Codex Desktop: 26.623.61825 / CFBundleVersion 4548
Install path: /Applications/Codex.app

Main app signing was OK in this case:

codesign --verify --deep --strict --verbose=2 /Applications/Codex.app
/Applications/Codex.app: valid on disk
/Applications/Codex.app: satisfies its Designated Requirement

spctl --assess --type execute --verbose=4 /Applications/Codex.app
/Applications/Codex.app: accepted
source=Notarized Developer ID

Local observations before cleanup:

Opening Codex correlated with elevated syspolicyd / trustd and heat.
Quitting Codex dropped syspolicyd and trustd back to 0%.
The Codex Chrome native host was present under the Chrome/Chromium NativeMessagingHosts directories.
~/.codex/computer-use was being recreated on Codex launch.
Even with computer-use@openai-bundled and chrome@openai-bundled disabled, Codex restored a notify = ["~/.codex/computer-use/.../SkyComputerUseClient", "turn-ended"] hook on launch and started SkyComputerUseService.
A separate non-OpenAI "Codex usage monitor" app was also installed locally. spctl rejected that app, so I removed it as a confounder before comparing Codex behavior.

Mitigation steps tried:

Backed up ~/.codex.
Removed the Codex Chrome native host manifests and Codex Chrome plugin cache.
Disabled chrome@openai-bundled, computer-use@openai-bundled, and record-and-replay@openai-bundled.
Removed the separate rejected "Codex usage monitor" app.
Reinstalled /Applications/Codex.app from the official DMG while preserving ~/.codex.

After those steps:

Codex open: syspolicyd stabilized around ~2.6-2.7%, trustd 0%
Codex quit: syspolicyd 0%, trustd 0%
Chrome native host files: not recreated
SkyComputerUseService: still recreated/running, but observed at 0% CPU

Additional duplicate/root-cause check:

I then checked trusted project roots in ~/.codex/config.toml, based on the broken .git reports above. One trusted workspace root contained an empty malformed .git directory:

trusted workspace root: <redacted cloud-storage workspace>
<root>/.git: empty directory, 0B
git -C <root> rev-parse --git-dir --is-inside-work-tree
fatal: not a git repository (or any of the parent directories): .git

I moved that empty .git directory aside rather than deleting it. This matches the workaround/root cause described by others in this issue, so I am adding it here instead of opening a duplicate issue.

The remaining potentially separate issue is that Codex 26.623.61825 still recreates ~/.codex/computer-use and restores the SkyComputerUseClient notify hook even when the Computer Use plugin is disabled. That appears related to #30298.

I dug into this on macOS 26.2 with ChatGPT/Codex Desktop 26.707.41301 (build 5103) and found a concrete cause for the repeating 32-event bursts.

An Endpoint Security trace shows the Electron sampler running two plain ps commands. /bin is 17th in the app’s PATH, so each command tries 16 earlier entries before reaching /bin/ps: 16 × 2 = 32 policy events. The ChatGPT/Codex path in the logs is simply what those children inherit before exec; in this capture, the app was not relaunching itself.

As a sanity check, I added a symlink to /bin/ps in the user-owned directory already first in PATH. The same app process and sampler kept running, but matching policy events stayed at zero for 120+ seconds and syspolicyd/trustd settled.

The direct fix seems to be using /bin/ps at both sampler call sites. #24234 shows the same bare ps call.

Current-build macOS reproduction: malformed trusted `.git` removal immediately stops `syspolicyd` / `trustd` storm

Adding a controlled A/B result from a current Codex Desktop build.

Environment

Codex Desktop: 26.707.72221 (build 5307)
Bundled Chromium: 150.0.7871.115
macOS: 26.5.2 (25F84)
Apple Silicon: M4 MacBook Air, 24 GB RAM

Before

Codex was running normally, but one explicitly trusted workspace contained an empty malformed Git directory:

<HOME>/Documents/Homelab/.git

The directory existed but contained none of the required Git control files:

HEAD: missing
config: missing
objects: missing
refs: missing
commondir: missing
gitdir: missing

git -C <workspace> rev-parse --git-dir --is-inside-work-tree returned:

fatal: not a git repository (or any of the parent directories): .git

The workspace was explicitly configured with trust_level = "trusted".

Observed sustained load across repeated samples:

syspolicyd: 341-367% CPU, ~329 MB RSS
trustd:      77-82% CPU,  ~17 MB RSS

A macOS resource report showed syspolicyd had dirtied approximately 2.15 GB of file-backed memory in its SQLite policy path. A contemporaneous open-file snapshot contained 21 entries for the Codex/ChatGPT main executable and 40 HTTPS connections to Apple 17.248.x.x endpoints.

The GUI process PATH was only:

/usr/bin:/bin:/usr/sbin:/sbin

Therefore the recently reported bare-ps PATH-search amplification does not match this reproduction.

Intervention

I renamed only the empty malformed directory:

.git -> .git.invalid-backup-20260714

I did not restart Codex, syspolicyd, trustd, or macOS.

After

Within approximately one minute:

syspolicyd: 0.0% CPU
trustd:     0.0% CPU

Both remained at 0% throughout a further two-minute 10-second-interval sample. syspolicyd RSS subsequently fell from about 328 MB to 131 MB while the same Codex Desktop process remained running.

A scan of all other currently existing trusted project roots found 10 valid Git repositories and no additional malformed .git directories.

Conclusion

This is a current-build confirmation that an empty/malformed .git directory under a trusted workspace can trigger the Codex-associated Gatekeeper/SystemPolicy storm. The no-restart A/B result strongly isolates removal of the malformed Git marker as the event that stopped the CPU runaway.

Suggested invariant: Codex should not treat the mere existence of .git as sufficient. It should validate repository state, bound retries/fallback process creation after rev-parse failure, and avoid repeatedly causing executable policy assessments for an invalid workspace.

Navigation Menu

Repository navigation

macOS Codex relaunch loop exhausts syspolicyd file descriptors and blocks app launches #25243

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

31 remaining items

Current-build macOS reproduction: malformed trusted `.git` removal immediately stops `syspolicyd` / `trustd` storm

Environment

Before

Intervention

After

Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

macOS Codex relaunch loop exhausts syspolicyd file descriptors and blocks app launches #25243

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on May 30, 2026

guidedways commented on May 30, 2026

guidedways commented on May 30, 2026

guidedways commented on May 31, 2026

guidedways commented on Jun 5, 2026

guidedways commented on Jun 5, 2026

hhcme commented on Jun 5, 2026

etraut-openai commented on Jun 5, 2026

guidedways commented on Jun 5, 2026

etraut-openai commented on Jun 5, 2026

guidedways commented on Jun 5, 2026

31 remaining items

guidedways commented on Jun 18, 2026

guidedways commented on Jun 18, 2026

andrea-sdl commented on Jun 18, 2026

guidedways commented on Jun 18, 2026

jamguoxiaoqi commented on Jun 24, 2026

apple-ouyang commented on Jun 24, 2026

apple-ouyang commented on Jun 24, 2026

goclaude commented on Jun 24, 2026

apple-ouyang commented on Jun 24, 2026

apple-ouyang commented on Jun 24, 2026

kedoupi commented on Jun 25, 2026

vokal-pe commented on Jun 25, 2026

nintendomustdie commented on Jun 29, 2026

ilmarioranen commented on Jul 11, 2026

kerimala commented on Jul 14, 2026

Current-build macOS reproduction: malformed trusted .git removal immediately stops syspolicyd / trustd storm

Environment

Before

Intervention

After

Conclusion

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Current-build macOS reproduction: malformed trusted `.git` removal immediately stops `syspolicyd` / `trustd` storm