macOS: Codex Desktop triggers sustained syspolicyd/trustd CPU spikes tied to Computer Use

Open 💬 3 comments Opened Jun 16, 2026 by mayunlei

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

High CPU State

On June 13, 2026, Codex Desktop triggered sustained high CPU usage on macOS 14.7.1 (23H222) on Apple Silicon. During the first capture, syspolicyd reached 136.3% CPU and trustd reached 62.4% CPU. After Codex was closed, the machine returned to normal. After Codex was reopened, the problem reproduced again within seconds, and the second capture showed syspolicyd at 180.7% CPU and trustd at 61.2% CPU.

Evidence

In a 15-minute capture window, Codex logged 1031 TCCAccessRequest() IPC events.
In the same window, trustd logged 671 warnings that the com.apple.security.application-groups entitlement for 2DC432GLL2.com.openai.sky.CUAService was ignored because of an invalid signature or incorrect provisioning profile.
In the same window, syspolicyd logged 23 failed to call driver: 0x3 events, along with repeated SecTrustEvaluateIfNecessary.
In the narrowed post-reopen window for the new Codex process, there were still 256 TCCAccessRequest() IPC events, 763 repeated trustd entitlement warnings, 97661 syspolicyd cache misses, and 40 trust evaluation events.

Correlation with Codex

The issue stops when Codex is closed.
The issue returns immediately after Codex is reopened.
The second reproduction used a fresh Codex PID tree, which makes this unlikely to be only a stale leftover process from an earlier session.
The active process chain during reproduction was Codex -> codex app-server -> SkyComputerUseService, followed by repeated trustd / syspolicyd security activity.
The repeated system warnings specifically mention com.openai.sky.CUAService, which ties the high-CPU activity to Codex Computer Use rather than to an unrelated background process.

Qualification

This evidence shows a strong runtime correlation between Codex Desktop, SkyComputerUseService, and the trustd / syspolicyd CPU spike. It does not by itself prove the exact root cause inside Codex, but it does show that opening Codex is the direct trigger for the repeated security and entitlement evaluation loop on this machine.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

#28250
#28100
#27891

Powered by Codex Action

muhammadsharief910-ops · 2 months ago

exact same issue

rokgregoric · 2 months ago

Adding another reproduction on the current Codex Desktop build.

Environment

Codex Desktop: 26.616.51431
Codex build: 4212
Bundle id: com.openai.codex
Install path: /Applications/Codex.app
macOS: 26.5.1 build 25F80
Architecture: arm64
Date observed: 2026-06-22

Behavior

While Codex Desktop is running, syspolicyd repeatedly climbs to high CPU. Quitting Codex makes syspolicyd drop back to 0%.

Activity Monitor screenshot captured during the issue showed:

Process: syspolicyd
CPU: 149.2%
CPU time: 20.79

I also captured a privacy-minimized process snapshot while Codex was active:

PID    PPID  %CPU  %MEM  ELAPSED  COMMAND
13679  1     81.2  1.8   02:03    /usr/libexec/syspolicyd
65175  1      0.6  1.0   38:04    /Applications/Codex.app/Contents/MacOS/Codex
65182  65175 21.9  0.3   38:03    /Applications/Codex.app/.../Codex (Service)
65466  65175  5.5  0.9   38:02    /Applications/Codex.app/Contents/Resources/codex
65514  65175  9.6  1.4   38:01    /Applications/Codex.app/.../Codex (Renderer)

One additional clue: there were many long-lived orphaned helper processes with PPID=1:

/Users/slider/.codex/computer-use/Codex Computer Use.app/.../SkyComputerUseClient

Several had elapsed times in the 18h to 22h range. This might be relevant if macOS is repeatedly validating helper apps or binaries under ~/.codex/computer-use.

Process arguments were intentionally omitted because they include thread content.