›_ Codex Issues
Codex Issues / #26795

Codex app on macOS triggers syspolicyd/trustd CPU loop and severely slows Xcode and Chrome

Open 💬 4 comments Opened Jun 6, 2026 by Joremando
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The Codex app on macOS appears to trigger a repeated macOS security validation loop involving syspolicyd and trustd.

When Codex is open, my Mac becomes extremely slow. Xcode takes a very long time to run a project, and Chrome becomes unresponsive or freezes. When I completely close Codex, Xcode runs almost immediately again and the high CPU usage from syspolicyd / trustd disappears.

This does not appear to be an Xcode project issue, a hardware issue, or a RAM issue. The slowdown is directly correlated with Codex being open.

Environment

  • Device: Apple Silicon Mac
  • RAM: 128 GB
  • macOS version: [insert macOS version]
  • Codex app version: [insert Codex version if available]
  • Xcode version: [insert Xcode version]
  • Chrome also affected: Yes

Observed behavior

While Codex is open:

  • The whole system becomes very slow.
  • Xcode Run becomes extremely delayed.
  • Chrome freezes or becomes unresponsive.
  • Activity Monitor shows high CPU usage from:
  • syspolicyd
  • trustd
  • WindowServer
  • Codex-related processes are also visible.
  • macOS logs show repeated security validation messages with rapidly increasing PIDs.

Example log output:

syspolicyd [...] [com.apple.syspolicy.exec:default] dispatch_mig_server returned 268435459
syspolicyd [...] <private> with PID 90040 violates validation category policy. This will likely result in a block in the future
syspolicyd [...] SecKeyVerifySignature
syspolicyd [...] SecTrustEvaluateIfNecessary
trustd [...] SecKeyVerifySignature
syspolicyd [...] SecTrustCopyAppleTrustAnchors

syspolicyd [...] <private> with PID 90041 violates validation category policy. This will likely result in a block in the future
syspolicyd [...] <private> with PID 90043 violates validation category policy. This will likely result in a block in the future
syspolicyd [...] <private> with PID 90044 violates validation category policy. This will likely result in a block in the future
syspolicyd [...] <private> with PID 90045 violates validation category policy. This will likely result in a block in the future

The PIDs keep increasing rapidly, suggesting that something related to Codex may be repeatedly launching or validating processes, triggering macOS Gatekeeper / Apple System Policy / trust validation in a loop.

Expected behavior

Codex should not trigger repeated macOS security validation loops or make unrelated apps like Xcode and Chrome unusable.

Actual behavior

With Codex open:

* Xcode Run is severely delayed.
* Chrome becomes unresponsive.
* syspolicyd and trustd consume significant CPU.
* macOS logs show repeated validation events with rapidly increasing PIDs.

With Codex closed:

* Xcode runs almost immediately.
* syspolicyd and trustd disappear from the top CPU list.
* The system returns to normal performance.

Reproduction steps

1. Open Codex app on macOS.
2. Open Xcode.
3. Run an iOS/macOS project.
4. Observe that Xcode Run becomes extremely slow.
5. Open Activity Monitor and sort by CPU.
6. Observe elevated syspolicyd and trustd.
7. Run:

log stream --predicate 'process == "syspolicyd" OR process == "trustd"' --style compact

8. Observe repeated security validation messages with rapidly increasing PIDs.
9. Completely close Codex.
10. Run the same Xcode project again.
11. Xcode runs almost immediately and syspolicyd / trustd CPU usage drops.

Workaround

Closing Codex restores normal Xcode performance.

Attachments

I can provide:

* Activity Monitor screenshot showing syspolicyd and trustd consuming high CPU while Codex is open.
* macOS log output showing repeated syspolicyd validation messages.
* Activity Monitor screenshot after closing Codex, showing normal CPU usage and Xcode running correctly.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25719
  • #25882
  • #26341
  • #26117
  • #25703

Powered by Codex Action

andersaamodt · 2 months ago

Additional sanitized diagnostics from a live reproduction on macOS 26.5.1 build 25F80, Apple Silicon:

The issue now looks like an interaction between Codex Desktop's macOS attestation/app-server path and a macOS syspolicyd resource leak. I think Apple owns the daemon/resource-leak bug, but Codex is currently the primary trigger on my machine and could likely mitigate it by reducing/caching/throttling the attestation path or by avoiding repeated launch-assessment pressure.

Current Codex build:

  • Codex Desktop 26.609.41114, build 3888
  • /Applications/Codex.app
  • signed by Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
  • stapled notarization ticket present
  • no com.apple.quarantine xattr
  • production Sparkle appcast still lists build 3888 as current

Most important live evidence:

  • syspolicyd reached multi-GB RSS and sustained high CPU while Codex was open.
  • A privileged lsof aggregate on live syspolicyd showed:
total open entries: 63086
entries for /Applications/Codex.app/Contents/MacOS/Codex: 63051
  • ExecPolicy.scan_targets_v2 had 0 unmeasured rows at the same time, so this was not just an uncleared assessment backlog.
  • Root-read SQLite integrity checks returned ok for both /var/db/SystemPolicyConfiguration/ExecPolicy and /var/db/SystemPolicyConfiguration/Tickets.
  • Unified logs and local breadcrumbs showed Codex using the DeviceCheck/attestation path. Bundle inspection found the app-server initialize capability sets requestAttestation on macOS, and the main process registers attestation/generate using Resources/native/devicecheck.node.
  • Disabling normal analytics in ~/.codex/config.toml did not disable this attestation capability path.

Suggested Codex-side mitigations:

  • Add a supported user/config kill switch for Desktop DeviceCheck/app-server attestation on macOS.
  • Cache attestation support/token results aggressively and avoid repeated DeviceCheck calls when the platform path is degraded.
  • Do not advertise requestAttestation on macOS unless it is strictly required for the current operation.
  • Add backoff/circuit-breaker behavior if devicecheckd/mobileassetd/syspolicyd or token generation becomes slow or repeatedly invoked.
  • Avoid any behavior that repeatedly forces assessment of /Applications/Codex.app/Contents/MacOS/Codex.

This is severe because once syspolicyd is wedged, unrelated apps can fail to launch and the Codex app itself can fail to restart.

nintendomustdie · 2 months ago

Adding a sanitized data point from a live repair on macOS 26.5.1 where the visible symptom was Homebrew and terminal startup failures, but the underlying pattern matches this issue.

Environment, sanitized:

  • macOS: 26.5.1, build 25F80, Apple Silicon
  • Codex Desktop: running from /Applications/Codex.app
  • Homebrew: 6.0.2 under /opt/homebrew
  • Shell: zsh

Observed behavior:

  • With Codex Desktop open, syspolicyd and trustd were persistently high CPU, roughly ~50% each.
  • Homebrew-managed binaries could hang before user code ran. Sampling affected processes showed they were stuck at _dyld_start with no library-load output.
  • Affected examples included starship, rg, and Homebrew's portable Ruby.
  • Because starship init zsh was in .zshrc, new Terminal/Ghostty sessions appeared unresponsive: zsh was waiting for starship to return.
  • brew --version and brew --prefix initially timed out. Some other brew commands could eventually return after a long delay.

Relevant diagnostics:

sample starship:
  main thread: _dyld_start (in dyld)
  physical footprint: ~96K

sample ruby:
  main thread: _dyld_start (in dyld)
  physical footprint: ~96K

log excerpts:
  syspolicyd: dispatch_mig_server returned 268435459
  syspolicyd: <private> with PID ... violates validation category policy
  trustd/syspolicyd: repeated SecKeyVerifySignature / SecTrustEvaluateIfNecessary / SecTrustCopyAppleTrustAnchors

Mitigation/repair sequence that worked:

  1. Temporarily disabled starship init zsh in .zshrc so terminals could open again.
  2. Quit Codex Desktop and waited for macOS security services to settle.
  3. Re-signed the minimal Homebrew startup path and selected affected Homebrew binaries with ad-hoc signatures, specifically Homebrew portable Ruby plus key affected commands such as git, rg, starship, and python3.
  4. Re-tested Homebrew after Codex was closed.

After that:

brew --version                         -> Homebrew 6.0.2
brew --prefix                          -> /opt/homebrew
brew config                            -> returned normally
brew list --formula --versions starship -> returned normally
git --version                          -> returned normally
rg --version                           -> returned normally
starship --version                     -> returned normally
syspolicyd/trustd CPU                  -> back to 0% at rest

This looks like Codex Desktop can trigger or amplify a macOS 26.x syspolicyd / trustd validation loop. Once that loop is active, unrelated Homebrew binaries may appear broken because process launch stalls at _dyld_start. The local Homebrew repair was only effective after Codex was quit and the validation loop stopped.

I am not including full local logs because they contain machine-specific paths and process context, but I can provide further redacted diagnostics if useful.

XavierGeerinck · 1 month ago

Same issue here, had to stop using it because of this