Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex app can enter an AppleSystemPolicy retry loop and drive syspolicyd/trustd high CPU on macOS [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#17225•Fetched 2026-04-10 03:43:45
View on GitHub
Comments
2
Participants
3
Timeline
4
Reactions
0
Author
xowenxxowenx
Participants
fableman73fableman73github-actions[bot]github-actions[bot]xowenxxowenx
Timeline (top)
commented ×2labeled ×2

Root Cause

This seems more like a Codex runtime state problem than a persistent macOS policy database problem, because the system recovered as soon as Codex was restarted.

Code Example

2026-04-09 21:12:04.848 Df kernel[...] (AppleSystemPolicy) ASP: Security policy would not allow process: 87793, /Applications/Codex.app/Contents/MacOS/Codex
2026-04-09 21:12:04.848 Df kernel[...] (AppleSystemPolicy) ASP: Could not find reference 26755285, process must have died
RAW_BUFFERClick to expand / collapse

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

26.406.31014

What subscription do you have?

Plus

What platform is your computer?

Darwin 23.6.0 arm64 arm

What issue are you seeing?

Codex.app on macOS entered a retry loop that repeatedly triggered AppleSystemPolicy / Gatekeeper checks, causing very high CPU usage in syspolicyd and trustd.

Observed impact:

  • syspolicyd reached about 131% CPU
  • trustd reached about 62% CPU
  • Codex itself was also consuming CPU
  • restarting Codex immediately resolved the issue

Key evidence from logs:

2026-04-09 21:12:04.848 Df kernel[...] (AppleSystemPolicy) ASP: Security policy would not allow process: 87793, /Applications/Codex.app/Contents/MacOS/Codex
2026-04-09 21:12:04.848 Df kernel[...] (AppleSystemPolicy) ASP: Could not find reference 26755285, process must have died

At the same time, syspolicyd logs were repeatedly showing:

  • SecTrustEvaluateIfNecessary
  • failed to call driver: 0x3

This looked like Codex itself was repeatedly being launched or retried and repeatedly hitting AppleSystemPolicy until the app was restarted.

What steps can reproduce the bug?

  1. Launch Codex on macOS.
  2. Use the app normally for a while with active terminal / agent activity.
  3. At some point, syspolicyd and trustd spike in Activity Monitor.
  4. Unified logs show repeated AppleSystemPolicy / syspolicyd messages.
  5. Restart Codex.
  6. CPU usage drops and the issue stops.

What I was able to verify:

  • spctl and gktool checks later passed for apps, so this did not look like a permanently broken signature or damaged SystemPolicy database.
  • The strongest signal was the AppleSystemPolicy kernel log explicitly naming /Applications/Codex.app/Contents/MacOS/Codex.

I do not yet have a minimal deterministic repro beyond the app entering this bad state during normal use.

What is the expected behavior?

Codex should not enter a process launch / retry loop that repeatedly triggers AppleSystemPolicy, syspolicyd, and trustd work. Normal app use should not drive sustained high CPU in those system security daemons.

Additional information

Additional context:

  • Apple Silicon Mac (M1)
  • macOS 23.6.0
  • Time observed: 2026-04-09 around 21:05 to 21:12, Asia/Shanghai (UTC+8)
  • Restarting Codex fixed the issue immediately

This seems more like a Codex runtime state problem than a persistent macOS policy database problem, because the system recovered as soon as Codex was restarted.

extent analysis

TL;DR

Restarting the Codex app immediately resolves the high CPU usage issue caused by the retry loop triggering AppleSystemPolicy checks.

Guidance

  • Verify that the issue is not related to a permanently broken signature or damaged SystemPolicy database by running spctl and gktool checks after the issue occurs.
  • Investigate the Codex app's runtime state to identify what causes it to enter the retry loop, focusing on terminal/agent activity.
  • Monitor system logs and CPU usage to detect when the issue starts, and restart the Codex app as a temporary workaround.
  • Consider debugging the Codex app's launch and retry mechanisms to prevent the loop from occurring.

Example

No specific code snippet is provided, as the issue seems related to the Codex app's internal state and interaction with system security daemons.

Notes

The issue appears to be specific to the Codex app on macOS, particularly on Apple Silicon Macs (M1) with macOS 23.6.0. The provided logs and observations suggest a runtime state problem within the Codex app.

Recommendation

Apply the workaround of restarting the Codex app when the issue occurs, as it immediately resolves the high CPU usage problem. This is recommended because the issue seems to be related to the Codex app's internal state, and restarting the app allows the system to recover without persistent damage.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#dependency conflict#environment setup#docker error#permission error#memory optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING