Skip to content

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

Open
Open
Codex app on macOS triggers syspolicyd/trustd CPU loop and severely slows Xcode and Chrome#26795
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformance

Description

@Joremando
Joremando
opened on Jun 6, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    performance
    on Jun 6, 2026

  2. github-actions commented on Jun 6, 2026

    @github-actions
    github-actionsBot
    on Jun 6, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. andersaamodt commented on Jun 15, 2026

    @andersaamodt
    andersaamodt
    on Jun 15, 2026

    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.

  4. nintendomustdie commented on Jun 27, 2026

    @nintendomustdie
    nintendomustdie
    on Jun 27, 2026

    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.

  5. XavierGeerinck commented on Jul 13, 2026

    @XavierGeerinck
    XavierGeerinck
    on Jul 13, 2026

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions