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

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

• #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 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, 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 no-active-thread-019e97e4-070b-7aa2-99ce-95bf97655b29 and 019e97e3-59a8-7332-ad12-4630aa8cad0f

Steps:

• Killed syspolicyd and trustd
• Upgrade Codex to 26.602.30954 build 3575
• Immediately hammers syspolicyd and my M3 Max spikes to 50%+ CPU usage
• Generate feedback
• Quit the app and downgraded to 26.519.81530
• CPU and syspolicyd back to normal

Version 26.602.40724 • Released Jun 5, 2026 no difference, 136% CPU usage, syspolicyd hangs, so does Codex repeatedly and everything slows down.

Feedback: no-active-thread-019ea3b7-861a-73c1-a278-aad9aeca102b

Computer Use seems to be the reason - I've turned it off, yet it gets re-installed repeatedly and causes a hang.

The main concern is that if Computer Use is turned off in settings, it should not install the computer-use folder in ~/.codex - it adds it regardless and this installed app is what's causing all the problems. I expect this to be installed only if and when I enable it in settings.

@etraut-openai I'm having the same issue. I'm in the EU so I don't have access to computer use, the bug appears right after starting.
Session id: no-active-thread-019ea63a-b71e-7210-9e70-3d903a1891be

Reverting to 26.519.81530 fixes the issue but automatic worktree creation is broken there :(

 sudo lsof -c syspolicyd | wc -l
    2577 # all of these are Codex app)
 log show --predicate 'eventMessage CONTAINS "would not allow" AND eventMessage CONTAINS "Codex.app"' --last 2h | grep -c Codex.app
13021

Severe system hang, 170%+ constant CPU usage

no-active-thread-019eb6ce-d5ff-7ab1-9a83-59dc3ef99a96

Codex
Version 26.608.12217 • Released Jun 9, 2026
© OpenAI

@etraut-openai it's been more than 2 weeks, numerous updates in between and every single one behaves the same way. Even if you turn off computer use, syspolicyd hangs the entire system the moment I launch Codex. Is there no solution to this?

I've tried clearing up nearly everything under ~/.codex and trying the latest version again, no luck. Simply installing it (and before I can even launch it), the fans go off and the computer hangs.

Stuck on version 26.519.81530 from 2 weeks ago.

Consolidating #25882 here. This is the canonical report for the macOS Codex relaunch loop causing syspolicyd/trustd pressure and app-launch failures, including reports with and without Computer Use enabled.

I'm also affected by this issue. An older build like 26.527.31326 (3390) works correctly.

I've been having these constant performance issues with Codex app since its initial release and it still didn't resolve.

This bug is a critical blocker to me (and many others I'd assume). The syspolicyd saturation slows the entire system, codex is slow, all my work is slowed, and the laptop is unusable on battery because it drains so fast. This is on a very powerful machine, m4 max 64gb ram. I hope this is being given top priority for a fix asap.

Cross-linking #28100, which I'm closing as a duplicate of this canonical issue. Adding two data points I didn't see explicitly covered in this thread, plus confirmation of the Computer-Use re-creation behavior.

Environment

• Codex Desktop 26.609.41114
• macOS 15.7.5 (24G624), Apple Silicon / ARM64E
• Plan: Pro

Two findings that may help narrow the cause:

1. The spikes happen while the app is idle, not only at launch or right after an update. syspolicyd reached ~450% CPU with trustd spiking alongside it after Codex was already open and sitting idle — no prompt, no active turn, no task. It calms down and then returns on its own later without me launching anything new.

1. Sandbox / approval mode is irrelevant. I reproduced it across all of: custom permissions, full access, approval_policy = "never", and sandbox_mode = "danger-full-access". None of them changed the behavior.

Sample evidence captured during a spike.

syspolicyd (pid 506) — Dispatch Thread Soft Limit: 64 reached in 1699 of 4894 samples; hot stacks are code-signing / notarization / YARA / signature verification:

DispatchQueue_124: com.apple.security.syspolicy.yara
SecStaticCodeCheckValidityWithErrors
Security::CodeSigning::SecStaticCode::staticValidate
Security::CodeSigning::checkNotarizationServiceForRevocation
Security::CodeSigning::SecStaticCode::validateDirectory
CMSDecoderCopySignerStatus
SecCmsSignedDataVerifySignerInfo_internal
SecKeyVerifySignature

trustd (pid 427) — certificate/signature verification on the same window:

DispatchQueue_80: com.apple.trustd.evaluation
SecCertificateIsSignedBy
SecKeyVerifySignature
SecKeyRunAlgorithmAndCopyResult
SecECPublicKeyCopyOperationResult
ccec_verify
ccec_verify_digest_ws

This is consistent with the fd-exhaustion / no-backoff relaunch mechanism written up in #25882: syspolicyd is repeatedly assessing code bundles/frameworks and asking trustd to verify cert chains.

Confirming the Computer-Use re-creation behavior others here have reported (@flitzrrr, @davidsupan, @DavidSchargel, @energissimo-mg):

• Disabled MCPs entirely → no effect, syspolicyd still spiked.
• Commented out the notify = [...] line pointing at SkyComputerUseClient → on restart Codex recreated it. (Per @davidsupan, setting notify = [] explicitly survives restart where commenting out does not — will try that next.)
• Moved ~/.codex/computer-use aside and recreated it empty → Codex recreated the bundle on restart. I eventually had to lock it with permissions/flags so it couldn't reinstall.
• After a reboot with Computer Use confirmed absent/blocked, the spikes still returned on reopening Codex.
• I never enabled or wanted Computer Use in the first place.

This corroborates the consensus that disabling Computer Use does not stop the loop — the relaunch mechanism is the root cause and the Computer-Use hook re-creation is an aggravator, not the sole trigger.

Collateral damage worth flagging: during the storm, unrelated apps failed to launch — Arc failed with a system-policy / code-signing error on its Sparkle framework, and launched fine only when Codex was closed, then broke again after Codex was reopened. One diagnostic attempt destabilized the machine into a crash/reboot.

Full original report with the raw samples is in #28100.

Follow-up to my earlier comment, with fs_usage evidence that pinpoints the assessment target. This looks like a no-denial variant of the loop — distinct from the fd-exhaustion/relaunch pattern in #25882.

Setup: notify = [] was already set (and survives restart, per @davidsupan's note), Computer Use blocked, browser/chrome plugins disabled. The spike still happens on every launch.

What's spiking syspolicyd: with Codex open, syspolicyd sits at ~170% CPU while emitting zero log lines and zero Gatekeeper denials. sudo fs_usage -f filesys syspolicyd shows why — several syspolicyd worker threads continuously re-stat64/access/getattrlist the app's own main executable, dozens of times within a few milliseconds:

stat64            /Applications/Codex.app/Contents/MacOS/Codex          syspolicyd.931560
stat64            /Applications/Codex.app/Contents/MacOS/Codex          syspolicyd.931119
stat64            /Applications/Codex.app/Contents/MacOS/Codex          syspolicyd.931562
stat64            /Applications/Codex.app/Contents/MacOS/Codex          syspolicyd.931564
access (R___)     /Applications/Codex.app/Contents/MacOS/Codex          syspolicyd.931560
getattrlist       /Applications/Codex.app/Contents/MacOS/Codex          syspolicyd.931560
getattrlist [20]  /Applications/Codex.app/Contents/MacOS/Codex/Wrapper  syspolicyd.931119
statfs64          /Applications/Codex.app/Contents/MacOS/Codex          syspolicyd.931570
...

Eight-plus distinct syspolicyd worker threads (931119, 931560, 931562, 931564, 931568, 931570, 931571, 931574…) all re-validate the same binary in a tight loop → thousands of full code-signature assessments/sec, each pulling in the YARA-scan + notarization-revocation work seen in stack samples. The …/Codex/Wrapper probe returns errno 20 (ENOTDIR) because the executable is a file, not a bundle — part of validateDirectory, repeated on every pass.

New trigger clue — it tracks window focus: switching focus away from Codex (even while it keeps running) settles syspolicyd back to idle; switching focus back to the Codex window immediately re-spikes it. That points at a window-activation / foreground code path repeatedly requesting a fresh Gatekeeper/SecCode assessment of the main binary, rather than a startup-only or relaunch-driven loop.

Environment: Codex Desktop 26.609.41114, macOS 15.7.5 (24G624), Apple Silicon.

Consistent with other reports: downgrading to 26.519.81530 avoids it; no config change on the current build stops it.

Controlled A/B isolating the notify/folder "recreation" behavior from the syspolicyd storm.

On the good build 26.519.81530, I unlocked ~/.codex/computer-use (it had been emptied + chflags uchg'd, with notify = []) and relaunched. Within ~3 seconds the app:

• recreated the folder — Codex Computer Use.app (the bundled helper) + config.json reappeared, and
• rewrote notify from [] back to the volatile helper path:

notify = ["/Users/<user>/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended", "--previous-notify", "[]"]

Note the --previous-notify "[]" argument: the app recorded that the user had set notify = [] and overrode it anyway.

Despite all of that, syspolicyd stayed at ~0% CPU (1.6% → 0.2%), with the restored helper codesign-valid ("satisfies its Designated Requirement") and zero Gatekeeper denials.

The same recreation/override behavior also occurs on the broken 26.609.41114 — but only there does syspolicyd run away (~170% sustained, re-assessing /Applications/Codex.app/Contents/MacOS/Codex on window focus, per my earlier fs_usage comment).

| | Recreates folder + rewrites notify | syspolicyd runaway |
|---|---|---|
| 26.609.41114 (broken) | yes | yes |
| 26.519.81530 (good) | yes | no |

Conclusion: the notify/folder "recreation" behavior is build-independent and not the cause of the CPU storm. The storm is the newer build repeatedly re-assessing its own main binary, independent of Computer Use being enabled or not. Worth separating these two in triage — disabling/locking Computer Use doesn't fix the storm, and the storm reproduces regardless of Computer Use state.

Separately, the --previous-notify/override behavior is still a real UX bug (it ignores an explicit notify = []), just not the performance one.

My issue with syspolicyd and trust has been automatically resolved last Monday by installing updated Codex, after this was monitoring and no spikes of syspolicyd were observed. after it was another update and all is good. one week already
Current version Version 26.609.41114 • Released Jun 12, 2026 works OK

Adding a local root-cause narrowing data point. This may be one concrete amplification path for the macOS syspolicyd pressure, separate from whether Computer Use is the original trigger.

Environment:

• Codex Desktop 26.609.41114
• macOS Apple Silicon
• Browser Use and Computer Use enabled during the latest verification window

What I observed before local PATH remediation:

• Codex Desktop had a periodic process/terminal-state probe that spawned ps.
• fs_usage -w -f exec showed Codex attempting to resolve ps through PATH rather than calling /bin/ps directly.
• With a long user PATH containing many user-writable/tool directories before /bin, each probe expanded into many failed posix_spawn attempts before finally reaching /bin/ps.
• In one sampled cadence, the same second contained roughly:
• about 40 failed PATH lookup attempts for ps
• about 2 successful /bin/ps executions
• matching AppleSystemPolicy activity attributed to /Applications/Codex.app/Contents/MacOS/Codex
• During the bad state, syspolicyd held large numbers of FDs pointing at the Codex main executable.

Local mitigation tested:

I changed only the user shell PATH, not Codex binaries and not macOS system files:

• removed stale / missing user PATH entries
• de-duplicated PATH
• moved /bin near the front while keeping /opt/homebrew/bin first to avoid changing Homebrew bash behavior
• resulting ps lookup shape became:

/opt/homebrew/bin/ps  -> miss
/bin/ps              -> hit

After restarting Codex Desktop:

70-second verification window:

fs_usage exact ps path breakdown:
10 /opt/homebrew/bin/ps
10 /bin/ps

AppleSystemPolicy lines matching Codex main executable: 0

syspolicyd FD snapshots:
t0   total_fds=38  codex_main_fds=2
t15  total_fds=36  codex_main_fds=0
t30  total_fds=35  codex_main_fds=0
t45  total_fds=35  codex_main_fds=0
t60  total_fds=35  codex_main_fds=0
t70  total_fds=35  codex_main_fds=0

After re-enabling Browser Use / Computer Use and restoring the previously disabled helper executables (extension-host, SkyComputerUseClient), I still see short syspolicyd FD bursts against the Codex main executable, but they release instead of growing monotonically.

5-minute window:

t0    codex_main_fds=2
t30   codex_main_fds=0
t60   codex_main_fds=0
t90   codex_main_fds=0
t120  codex_main_fds=0
t150  codex_main_fds=0
t180  codex_main_fds=52
t210  codex_main_fds=125
t240  codex_main_fds=66
t270  codex_main_fds=0
t300  codex_main_fds=66

Follow-up 3-minute FD-only window:

t0    codex_main_fds=0
t30   codex_main_fds=71
t60   codex_main_fds=0
t90   codex_main_fds=0
t120  codex_main_fds=61
t150  codex_main_fds=0
t180  codex_main_fds=0

During this later window, extension-host and SkyComputerUseClient were running.

Interpretation:

This does not prove the whole macOS / AppleSystemPolicy FD lifecycle, and it does not rule out Computer Use / Browser Use as additional triggers. But it does suggest that Codex's process probe is using PATH-based resolution for ps, which can become a large multiplier on machines with long user PATHs.

Upstream hardening suggestion:

• call /bin/ps directly for this probe, or run it with a sanitized minimal PATH
• avoid allowing a routine process-state probe to use the full user shell PATH
• keep any helper launch / probe loop bounded with backoff / single-flight / circuit-breaker behavior
• preserve the disabled state for Computer Use / Browser Use, but do not rely on users disabling helpers as the only mitigation

This changed the issue on my machine from monotonic syspolicyd FD runaway to short, self-releasing bursts.

Corroboration of the PATH-amplification finding — independent machine, same-build / same-daemon A/B.

Following the earlier report that a long user PATH (many user-writable dirs before /bin) amplifies the syspolicyd re-assessment loop, I reproduced both the amplifier and a mitigation on 26.609.41114 (current latest), Apple Silicon, macOS 15.7.5.

Before: my login PATH had /bin at position 10, with 5 user-writable dirs searched before it (gcloud, nvm, vite-plus, homebrew/bin, homebrew/sbin). Codex inherits this via its shell_snapshot feature.

**A/B — same build, same syspolicyd daemon (PID 506, never restarted, 21h uptime):**

| State | syspolicyd |
|---|---|
| PATH unchanged | ~170% sustained — runaway |
| /bin hoisted to position 1 (nothing else moved), relaunched | peak ~38%, releases to ~0 — bounded bursts |

In both states fs_usage -f filesys syspolicyd shows ~8–10 worker threads re-assessing /Applications/Codex.app/Contents/MacOS/Codex (stat64/access/getattrlist, the …/Codex/Wrapper [20] ENOTDIR probe, and _CodeSignature/CodeRequirements-1). The fix didn't stop the re-assessment — it stopped it accumulating into a runaway.

Two caveats:

1. The relaunch is bundled with the PATH change, so this isn't a pure isolation of the PATH variable (the decisive test would be reverting only the /bin line). But same-build + same-never-restarted-daemon makes the hoist the most likely cause, and it matches the prior independent report.
2. The underlying defect persists. Codex still triggers a full Gatekeeper re-assessment of its own main binary on every window-focus change — focus the window → burst, defocus → idle. The PATH fix only bounds it.

Trigger worth emphasizing for whoever picks this up: the re-assessment is window-focus-driven, not startup-only or timer-based. That points at a focus/activation handler re-running a SecCode/Gatekeeper check on the main bundle.

Net: a PATH with /bin early can convert the runaway into bounded bursts on the current build — a usable workaround — but the real fix still needs the per-focus re-assessment cached/single-flighted upstream, and/or any process probe (ps) invoked by absolute path or with a sanitized minimal PATH.

Additional data point from Codex Desktop 26.609.41114 (build 3888) on macOS 26.5.1 (25F80), Apple Silicon.

This may be a separate amplifier rather than the primary relaunch/PATH issue described above:

• On each Codex.app launch I see a large Chromium code-sign clone under /var/folders/.../X/com.openai.codex.code_sign_clone.
• Current clone: one top-level code_sign_clone.* dir, ~1.2 GB, 8,269 files, 30 CodeResources, containing Codex.app.bundle.
• While Codex is running, lsof +D shows the Codex main process holding the cloned Contents/MacOS/Codex path. That file is hard-linked to /Applications/Codex.app/Contents/MacOS/Codex (same inode/link count 2); larger payloads such as app.asar and Codex Framework are separate copies.
• On normal quit via AppleEvent, Codex main process and SkyComputerUseService exit within 5s. From +5s through +60s, lsof +D shows no holders under the clone dir, but the 1.2 GB clone remains.
• No code_sign_clone, code-sign-clone, or MacAppCodeSignClone cleanup entries appeared in the quit-window system log.
• Local limits/context: launchctl limit maxfiles reports soft 256 / hard unlimited; during the bad state the Codex main process had ~255 open entries.

I do not think this proves code_sign_clone is the root cause. It does look like it could amplify the SystemPolicy/Gatekeeper work and the "too many open files" failure mode, especially if Chromium macOS code-sign clone cleanup is not running on normal Codex quit.

This also seems distinct from the PATH /bin/ps amplifier reported above; both could be present on the same machine.

Additional findings: PATH lookup appears to amplify syspolicyd / trustd

I investigated this locally because I was seeing intermittent Computer Use validation failures with too many open files after restarting Codex.app.

Environment:

• macOS 26.5.1, build 25F80
• Codex Desktop 26.609.41114, build 3888
• Chromium base 149.0.7827.54
• GUI launchd maxfiles: soft 256, hard unlimited
• /Applications/Codex.app passes spctl / notarization checks

I compared two Macs on the same macOS and Codex Desktop versions:

• Affected MacBook: reproducible launch-time syspolicyd spikes and prior too many open files failures around Computer Use validation.
• Control Mac mini: also accumulates code_sign_clone directories, but did not reproduce the severe spike or FD failure.

What seems relevant

code_sign_clone is created on every Codex.app launch under:

$(dirname "$(getconf DARWIN_USER_TEMP_DIR)")/X/com.openai.codex.code_sign_clone

On the affected MacBook, before cleanup I saw 9.4G / 8 clone directories / 66,152 files. After normal Codex.app quit, the clone directory remained, and lsof +D reported no holder. The Mac mini showed the same clone accumulation behavior, so I do not think clone retention alone is sufficient to explain the severe failure, but it is likely an amplifier.

The bigger difference was PATH shape:

• Affected MacBook: 53 PATH entries, /bin at position 44, many mise-managed user-writable directories before system directories.
• Control Mac mini: fewer PATH entries, system directories much earlier.
• ps exists only at /bin/ps on both machines.

Validation

After a clean reboot on the affected MacBook:

| Test | PATH condition | syspolicyd peak | trustd peak |
| --- | --- | ---: | ---: |
| Normal launch | /bin late in login-shell PATH | 120.4% | 25.5% |
| Temporary launchd PATH | /bin:/usr/bin:/usr/sbin:/sbin | 41.0% | 19.7% |
| Normal launch again | launchd PATH restored | 150.6% | 85.7% |
| Gated zsh PATH hoist | shell startup hoisted /bin:/usr/bin:/usr/sbin:/sbin | 0.2% | 3.3% |

This made PATH lookup the strongest local signal.

Exec evidence

A root fs_usage -f exec capture during a clean-clone Codex launch showed Codex-related spawns of:

• /bin/ps
• /usr/bin/ditto
• /usr/bin/sw_vers
• /usr/bin/xcode-select
• Git activity via the configured Homebrew Git path and related helpers

The clearest trace was xcode-select: Codex attempted many PATH entries before finally reaching /usr/bin/xcode-select. The failed attempts included my shim directory, many ~/.local/share/mise/installs/... directories, cargo, Homebrew, mise shims, /usr/local/bin, and the Cryptex app /usr/bin path.

In the same clean-clone exec run:

• syspolicyd peak: 50.9% at +5s
• trustd peak: 34.7% at +5s
• Codex main lsof rows peaked at 229
• Codex recreated one clone: 1.2G / 8,269 files
• After normal quit, Codex Desktop and SkyComputerUseService were gone, lsof +D reported no clone holder, but the clone root remained

A separate fs_usage -f filesys run directly showed the Codex process creating the com.openai.codex.code_sign_clone root and a code_sign_clone.* child directory. It also showed syspolicyd checking /Applications/Codex.app and the copied ~/.codex/computer-use/Codex Computer Use.app, and ditto copying the bundled Computer Use app out of /Applications/Codex.app.

Local mitigation

I added a narrow PATH shim at the front of my login shell PATH:

export PATH="$HOME/.local/share/codex-path:${PATH#$HOME/.local/share/codex-path:}"

The shim directory is mode 555 and currently contains:

ps           -> /bin/ps
ditto        -> /usr/bin/ditto
sw_vers      -> /usr/bin/sw_vers
xcode-select -> /usr/bin/xcode-select
git          -> /opt/homebrew/bin/git

For git, I resolved the current PATH order with whence -a git and pointed the shim to the first real non-shim git already active in my normal environment. On this machine that is /opt/homebrew/bin/git, not /usr/bin/git.

I used this targeted shim instead of moving /bin:/usr/bin:/usr/sbin:/sbin ahead of the whole PATH because it preserves my normal developer-tool resolution order and only changes the specific commands observed in Codex startup diagnostics.

If later diagnostics find more internal bare system-tool invocations, this shim directory can be extended narrowly by adding more symlinks to the intended system binaries. With the current shim in place, clean-clone validation runs stayed below the original 120-150% syspolicyd peaks, though there was still run-to-run variance. The shim is only a local mitigation, not a real fix.

Hypothesis / upstream suggestions

My current hypothesis is:

1. Codex startup invokes some system tools by bare name through PATH.
2. On machines with long PATHs and many user-writable directories before /bin and /usr/bin, macOS execution policy / Gatekeeper work is amplified by failed PATH lookups or spawn attempts.
3. code_sign_clone accumulation adds a large signed-app-like temporary tree and likely increases the amount of signing/filesystem work, but is not sufficient by itself.
4. The GUI launchd soft maxfiles limit of 256 makes the failure mode worse when Codex is already around 220-230 open files.

Potential upstream hardening:

• Use absolute paths or a sanitized PATH for internal Apple system tools:
• /bin/ps
• /usr/bin/ditto
• /usr/bin/sw_vers
• /usr/bin/xcode-select
• Be intentional about git: inherit the user's developer PATH if needed, but avoid repeated PATH scans where possible.
• Clean up stale code_sign_clone directories on normal termination or next startup when no process holds them.

Additional current repro from another affected macOS system, sanitized to avoid local usernames, account info, project paths, or thread contents.

Environment:

• macOS 26.5 / Darwin 25.5.0 / Apple Silicon
• Codex Desktop: 26.609.71450, build 3965
• Codex Computer Use app: 1.0, build 809
• SkyComputerUseClient: 1.0, build 809

Observed behavior:

• Launching/using Codex Desktop still triggers the same system-wide syspolicyd runaway described in this issue.
• In the current reproduction, syspolicyd reached ~143% CPU and ~2.6 GB RSS after ~14 minutes with Codex open.
• Codex Desktop, codex app-server, SkyComputerUseService, and multiple cua_node/bin/node_repl processes were present.
• The local Codex config still had the turn-ended notify hook routed through SkyComputerUseClient under the Computer Use install path.
• User-visible impact is severe: app launches become unreliable/system-wide, and killing syspolicyd/trustd does not recover cleanly while Codex/Computer Use is still running because the bad state appears to recur.

Why this looks like the same unresolved bug:

• The affected installation is newer than the attempted 26.602.30954 fix mentioned above.
• The installed Computer Use helper is still build 809, matching newer reports that 26.609.x still reproduces the issue.
• The practical workaround remains to stop Codex/Computer Use before restarting syspolicyd/trustd, or downgrade to 26.519.81530 where users in this thread reported the issue stops.

I am intentionally not pasting raw ps, lsof, unified log, or config output here because those can contain local identifiers or thread data. The sanitized finding is: 26.609.71450 + Computer Use/SkyComputerUseClient 1.0 build 809 still reproduces the syspolicyd runaway and system-wide app launch failure mode.

Feedback session ID uploaded via /feedback: 019e873a-d51a-7c12-9a7c-ea275eb84801

Reproducible on Codex Desktop 26.609.71450 (build 3965) — the 26.602.30954 fix attempt does not resolve it

Fresh repro with macOS-generated diagnostics, on a build newer than the attempted fix.

Environment

• macOS 26.2 (25C56), Apple Silicon (MacBookPro18,4, 32 GB)
• Codex Desktop 26.609.71450 (build 3965)
• Bundle com.openai.codex, notarized Developer ID (OpenAI OpCo, LLC — 2DC432GLL2)

Symptoms

• syspolicyd sustained 13–23% CPU, RSS ballooned to ~3.2 GB (from ~100 MB baseline).
• System-wide launch failures: OrbStack, Telegram and Codex itself hung; spctl --assess /Applications/Codex.app returned Too many open files (EMFILE).
• syspolicyd did not self-recover after I killed every Codex process — it stayed pegged at ~17% CPU / 3.2 GB and kept writing its ExecPolicy WAL for ~10 min with no Codex running (livelock in syspolicyd's own state, not just live load).

Evidence (/Library/Logs/DiagnosticReports, OS-generated)

• syspolicyd "disk writes" microstackshot: dirtied 2147 MB to its SQLite store over 3316 s; heaviest stack is a pure WAL-commit loop: sqlite3_step → vdbeCommit → sqlite3PagerCommitPhaseOne → pagerWalFrames → unixWrite → guarded_pwrite_np; footprint grew 113 MB → 1146 MB. Attribution: "On Behalf Of: Autoupdate (originated by Codex)".
• codex "disk writes" report: dirtied 8589 MB over 3399 s (~2.5 MB/s sustained).
• On-disk /var/db/SystemPolicyConfiguration/ExecPolicy grew to 20 MB with an actively-written WAL.

Contributing trigger (matches #25719)
~/.codex/config.toml had notify pointed at the volatile helper path ~/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient (turn-ended).

Recovery note

• sudo launchctl kickstart -k system/com.apple.security.syspolicy is blocked by SIP (150: Operation not permitted while System Integrity Protection is engaged).
• sudo killall syspolicyd trustd works and restores app launching (quit Codex first, otherwise it re-triggers).

Happy to run /feedback and post a session ID if useful.

Additional evidence: invalid project roots can drive the stable-metadata / git worker path into the syspolicyd FD issue

I have an additional local root-cause data point from macOS on 2026-06-16. It seems to connect two previously reported threads:

• non-Git / invalid Codex project entries causing repeated stable-metadata / workerId=git failures, as described in #19201
• Codex Desktop causing syspolicyd file descriptor pressure / Gatekeeper launch failures, as tracked in the syspolicyd issue thread

What was different in this reproduction

The trigger was not Computer Use, TCC, SIP, Edge, WPS, or a damaged Codex signature. The trigger was a large set of stale project roots in ~/.codex/config.toml.

Local audit:

Codex project entries: 239
Bad project roots: 213
  MISSING: 50
  NONGIT: 163
Valid Git roots kept: 26

Most bad entries were projectless scratch conversation directories under a Documents/Codex/YYYY-MM-DD/... style tree. They appear to have been created by projectless / attachment-style Codex Desktop or VS Code bridge chats and later trusted as projects.

Evidence

• sample on the Codex GUI process showed a Node/Electron Thread: git worker calling uv_spawn -> posix_spawn.
• fs_usage -f exec showed repeated posix_spawn attempts from Codex during the failure window.
• Kernel logs showed repeated AppleSystemPolicy denials against the Codex main executable.
• codesign and spctl passed for Codex itself, so this was not a damaged-signature issue.
• Disabling/killing Computer Use did not stop the FD growth on this machine.
• syspolicyd held many file descriptors pointing at /Applications/Codex.app/Contents/MacOS/Codex.

Fix / workaround that stopped it

I backed up and cleaned ~/.codex/config.toml, removing all MISSING and NONGIT project blocks while keeping only valid Git project roots.

After restarting Codex:

config_project_count=26
non_git_project_roots=0
syspolicyd Codex FD samples over ~90s: 0 -> 0 -> 0 -> 0
Gatekeeper checks for Codex / Edge / WPS: accepted / launched successfully

Hardening that prevented recurrence

Because Codex Desktop can create new trusted project entries for projectless scratch roots, I also made the scratch root a local-only Git repository with only a .gitignore committed:

*
!.gitignore

That makes future Documents/Codex/YYYY-MM-DD/... scratch children resolve through git rev-parse --show-toplevel instead of being classified as NONGIT.

I also moved the scratch directory out of iCloud Drive and replaced the original path with a symlink to avoid cloud-sync side effects, although the main trigger was the invalid/non-Git project metadata.

Suggested product-side fix

The app should treat invalid project roots as a bounded metadata failure:

• do not keep retrying git rev-parse --show-toplevel aggressively for MISSING / NONGIT project roots
• evict or quarantine invalid project entries after a small retry budget
• do not let the stable-metadata / git worker repeatedly posix_spawn commands in a way that cascades into Gatekeeper re-assessment of the Codex main binary
• consider not trusting projectless scratch conversation directories as persistent projects unless their root is already a valid repository

This workaround fully stopped the issue locally without changing SIP, SystemPolicyConfiguration, TCC, Computer Use, or reinstalling Codex.

@daihao1975-dotcom thank you!!! This was it!

@etraut-openai it was stale projects listed in config.toml causing this all along! Just cleaned up my config, updated and no more freezes!

Update: spoke too soon, I'm seeing syspolicyd flooded with

/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

> And the CPU% is back up :(

Second Update: I removed ALL the projects listed under config.toml and now it's back to 0.0% CPU!!

Nope, it's back again. Now I see syspolicyd flooded with

/private/var/folders/78/my0llvrj17g_r2p6whxjwr9h0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.w6CQA5/Codex.app.bundle/Contents/MacOS/Codex
/private/var/folders/78/my0llvrj17g_r2p6whxjwr9h0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.w6CQA5/Codex.app.bundle/Contents/MacOS/Codex
/private/var/folders/78/my0llvrj17g_r2p6whxjwr9h0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.w6CQA5/Codex.app.bundle/Contents/MacOS/Codex
/private/var/folders/78/my0llvrj17g_r2p6whxjwr9h0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.w6CQA5/Codex.app.bundle/Contents/MacOS/Codex
/private/var/folders/78/my0llvrj17g_r2p6whxjwr9h0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.w6CQA5/Codex.app.bundle/Contents/MacOS/Codex
/private/var/folders/78/my0llvrj17g_r2p6whxjwr9h0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.w6CQA5/Codex.app.bundle/Contents/MacOS/Codex
/private/var/folders/78/my0llvrj17g_r2p6whxjwr9h0000gn/X/com.openai.codex.code_sign_clone/code_sign_clone.w6CQA5/Codex.app.bundle/Contents/MacOS/Codex

Stuck on Version 26.519.81530 (3178) I guess. No luck updating Codex.

Follow-up after reading @guidedways' latest verification and the code_sign_clone/.../Codex.app.bundle/Contents/MacOS/Codex recurrence.

I agree that my earlier config.toml cleanup should not be read as “the whole bug is only stale projects in config”. On my affected machine, cleaning ~/.codex/config.toml was necessary but not sufficient once Codex Desktop had already rehydrated stale workspace/projectless state.

The recurrence path I saw locally was:

1. config.toml had already been cleaned (codex-prune-projects --dry-run reported no invalid project roots).
2. Codex Desktop still had projectless/workspace state in other local state stores.
3. A dirty relaunch from VS Code inherited TERM_PROGRAM=vscode, VSCODE_*, PWD=$HOME, and a long PATH where system dirs were late.
4. The GUI process still showed a Thread: git worker with uv_spawn -> posix_spawn in samples.
5. syspolicyd continued to accumulate FDs on the Codex binary until the old Codex process was fully exited and relaunched with a clean environment.

The additional local cleanup that made the fix stick here was:

• Clear projectless/workspace mappings in ~/.codex/.codex-global-state.json, especially:
• projectless-thread-ids
• thread-workspace-root-hints
• thread-projectless-output-directories
• stale/non-git entries in active-workspace-roots, electron-saved-workspace-roots, and project-order
• Check both local sqlite state DBs for active non-git / projectless cwd rows:
• ~/.codex/state_5.sqlite
• ~/.codex/sqlite/state_5.sqlite
• Keep the projectless scratch/output root git-backed so future scratch children are not classified as NONGIT.
• Relaunch Codex Desktop from a clean launchd environment:
• no TERM_PROGRAM=vscode
• no VSCODE_*
• PATH begins with /usr/bin:/bin:/usr/sbin:/sbin
• PWD points at a real git workspace, not $HOME

After that, with the GitHub plugin still enabled, my final verification was:

Codex env: no VS Code variables
Codex PATH: /usr/bin:/bin:/usr/sbin:/sbin first
GitHub plugin: enabled
trusted projects: remove=0
projectless/hints/outputs: 0/0/0
Xcode: launches/runs
Mail app: launches/runs

syspolicyd did still show startup/plugin-activation FD spikes after the clean relaunch, including one restart around ~1.5k Codex FDs, but the important difference was that the FDs were released instead of growing monotonically. A later 70s sample settled to:

syspolicyd total/top Codex path samples:
94/72 -> 118/96 -> 118/96 -> 118/96 -> 46/24 -> 46/24 -> 46/24

So my current interpretation is:

• stale/invalid project roots are one real trigger/amplifier, especially when projectless scratch directories are persisted as projects;
• cleaning only config.toml may not be enough because Desktop can rehydrate stale projectless/workspace state from global state or sqlite session state;
• dirty GUI launch environment / PATH shape is another amplifier;
• code_sign_clone may be a separate remaining amplifier or visible target path, especially when the old state is only partially cleaned;
• a single FD snapshot can be misleading: on a healthy-ish run I now expect a startup spike followed by release, not necessarily zero immediately.

A useful product-side mitigation would be to quarantine/evict invalid projectless workspace roots across all Desktop state stores, not only config.toml, and to run internal system-tool probes (ps, ditto, sw_vers, xcode-select, etc.) with absolute paths or a sanitized PATH.

@daihao1975-dotcom I've tried deleting the entire .codex folder, no help. I thought it did but then after a moment the CPU climbs back to 140% and syspolicyd is spammed with Codex listings.

I guess I'm stuck for now.

@guidedways Deleting the whole ~/.codex directory may still miss two parts of the loop I saw locally:

1. the parent GUI launch environment / PATH that Codex inherits from launchd or the app that launched it;
2. Chromium's code_sign_clone / Computer Use recreation path, which can be rebuilt after ~/.codex is removed.

On my machine, the current state is not "zero pressure" either. Under a deliberate multi-agent stress test, syspolicyd still spiked, but it did not grow monotonically:

sample interval: 30s
samples captured: 51 (~25 min, stopped early by user)
max Codex top_count: 3789 @ 16:14:02
min Codex top_count: 3 @ 16:13:01
last captured top_count: 325 @ 16:26:51
pid changes: 43

So this is only a guarded/local-containment result, not proof that the upstream issue is gone. My local acceptance criterion is now: app launches remain usable, and the FD count releases or is reset instead of climbing forever. During heavy Codex usage, the remaining pressure is still real.

If your CPU goes back to ~140% after deleting ~/.codex, I would check these separately from config cleanup:

launchctl getenv PATH
ps eww -p $(pgrep -x Codex | head -1) | tr ' ' '\n' | egrep '^(PATH|PWD|TERM_PROGRAM|VSCODE_)='
sudo lsof -nP -p $(pgrep -x syspolicyd | head -1) | egrep 'Codex.app|code_sign_clone' | head

In my case, a dirty launch path showed up as:

• TERM_PROGRAM=vscode / VSCODE_* inherited by the Codex GUI process;
• system dirs not first in PATH;
• later, even with the GUI process clean, child processes such as codex app-server / node_repl still had a long PATH with user/tool directories before /usr/bin:/bin;
• notify was recreated to point at SkyComputerUseClient.

That makes me think there are at least three amplifiers here: stale workspace/projectless metadata, dirty PATH / bare system-tool spawning, and code_sign_clone / Computer Use recreation. Cleaning .codex helps only the first class, and may immediately recreate the third.

In that case, this is precisely what I encountered. There was a non-zero pressure, and syspolicyd was consistently reaching around 26%-50% of the CPU (not as severe as 200%). Additionally, the entries were _slowed down_ to every two or so seconds under Activity Monitor. For my specific use case, anything above 0% is unfortunately going to impact my work (and sanity) and potentially only exacerbate my anxiety 😆

For folks still trying different workarounds: I documented my local investigation and mitigation here: https://github.com/openai/codex/issues/25243#issuecomment-4709140592

This is not a confirmed upstream fix, but on my affected Mac the strongest local evidence was PATH lookup amplification: Codex was invoking some tools by bare command name, and a long user PATH with many mise-managed directories before the system dirs caused repeated SystemPolicy/Gatekeeper work. A narrow PATH shim for the observed commands (ps, ditto, sw_vers, xcode-select, and my first selected git) has kept my machine stable across restart/update/heavy-use checks so far.

The newer comments about stale/invalid project roots and code_sign_clone/.../Codex.app.bundle/Contents/MacOS/Codex still look important too. My mitigation does not claim to solve every trigger path, but it may help distinguish PATH amplification from the remaining code_sign_clone / metadata-probing issues.

Adding a sanitized repro/data point. I am deliberately omitting local usernames, home paths, project names, hostnames, account/session IDs, and raw logs.

Current affected machine checked:

• macOS 26.5.1 / build 25F80
• arm64
• Codex Desktop 26.611.61753 / bundle 4008

This same class of failure is reproducible across three separate Macs here. Common pattern:

1. Start from a recovered state: quit Codex Desktop, restart syspolicyd, then verify spctl --assess --type execute --verbose=4 /System/Applications/Calculator.app returns accepted.
2. Launch or leave Codex Desktop running.
3. syspolicyd begins accumulating file descriptors whose path is overwhelmingly:

``text
/Applications/Codex.app/Contents/MacOS/Codex
``

1. In one captured run after restarting syspolicyd, the Codex FD count grew roughly like this within about a minute:

``text
227 -> 296 -> 651 -> 2335 -> 2535
``

1. Once the bad state is reached, unrelated Gatekeeper assessments fail globally. For example, Calculator moves from accepted to Too many open files, and unrelated apps cold-launch very slowly or stall.
2. Quitting Codex Desktop and restarting syspolicyd restores spctl for unrelated apps. With Codex still closed, syspolicyd returns to a low FD baseline and unrelated apps launch normally.
3. codesign --verify --deep --strict on Codex and affected unrelated apps passes, so this does not look like a corrupt app bundle or a single third-party app issue.
4. sample syspolicyd during the bad state showed work concentrated around the SystemPolicy/YARA/code-signing path, including com.apple.security.syspolicy.yara and SecStaticCodeCreateWithPath.

This matches the reports here that Computer Use may be one trigger/amplifier, but it does not appear to be the only one. In this reproduction, the strongest public-safe signal is syspolicyd repeatedly retaining FDs to the Codex main executable itself.

Expected product behavior: Codex should not repeatedly trigger Gatekeeper/SystemPolicy assessment of its own executable or helpers in a way that lets syspolicyd accumulate unreleased FDs and break system-wide app launching. Any relaunch/helper-validation loop should have backoff/caps, and Desktop should have a safe mode or feature-disable path that avoids high-risk helper/plugin startup while this is being diagnosed.

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

<img width="876" height="536" alt="Image" src="https://github.com/user-attachments/assets/a8b6071a-fe82-4a58-b457-47182ab21f67" />

@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: https://github.com/openai/codex/issues/25243#issuecomment-4709140592

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

@andrea-sdl ask codex to look at https://github.com/openai/codex/issues/25243#issuecomment-4709140592 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.

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.

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:

1. Inspect trusted project roots in ~/.codex/config.toml.
2. For each trusted root, check whether $root/.git exists and whether git -C "$root" rev-parse --git-dir --is-inside-work-tree succeeds.
3. Move malformed .git shells to Trash after confirming they are not real repositories.
4. 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.

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:

1. Backed up ~/.codex.
2. Removed the Codex Chrome native host manifests and Codex Chrome plugin cache.
3. Disabled chrome@openai-bundled, computer-use@openai-bundled, and record-and-replay@openai-bundled.
4. Removed the separate rejected "Codex usage monitor" app.
5. 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.