Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway

7 min read Original article ↗

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

Codex Desktop: 26.527.60818 Codex build: 3437

What subscription do you have?

plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex Desktop for macOS triggers a persistent macOS Gatekeeper/SystemPolicy loop after launch. With Codex closed, the system is quiet. As soon as Codex Desktop is opened, /usr/libexec/syspolicyd rises to very high CPU usage and grows to multiple GB of RAM. This happens even after replacing Codex with a freshly downloaded DMG build.

This appears related to Codex Desktop launching or validating its bundled/helper components, including Codex Computer Use, but the problem also reproduces after user-facing Browser/hotkey/notify settings were disabled.

What steps can reproduce the bug?

Reproduction steps

  1. Boot macOS normally.

  2. Ensure Codex Desktop is closed.

  3. Observe Activity Monitor: CPU is normal.

  4. Run:

    sudo killall -9 syspolicyd trustd

  5. Confirm CPU is still normal.

  6. Open Codex Desktop.

  7. Observe syspolicyd rising to very high CPU and memory usage.

The same pattern was observed after manually replacing Codex with the latest freshly downloaded DMG build.

What is the expected behavior?

No response

Additional information

Summary

Codex Desktop for macOS triggers a persistent macOS Gatekeeper/SystemPolicy loop after launch. With Codex closed, the system is quiet. As soon as Codex Desktop is opened, /usr/libexec/syspolicyd rises to very high CPU usage and grows to multiple GB of RAM. This happens even after replacing Codex with a freshly downloaded DMG build.

This appears related to Codex Desktop launching or validating its bundled/helper components, including Codex Computer Use, but the problem also reproduces after user-facing Browser/hotkey/notify settings were disabled.

Environment

Device: Apple Silicon MacBook Air, M5
macOS: 26.5
Build: 25F71
Codex Desktop: 26.527.60818
Codex build: 3437
Timezone: Europe/Rome
Date observed: 2026-06-01 / 2026-06-02

Previous Codex version also affected:

Codex Desktop: 26.527.31326
Build: 3390

Main symptom

When Codex is closed:

CPU usage is normal.
Activity Monitor is quiet.
syspolicyd / trustd are not consuming significant resources.

When Codex is opened:

/usr/libexec/syspolicyd immediately rises to very high CPU usage.
CPU observed: approximately 125% to 200%.
Memory observed: over 8 GB RSS in one run.
trustd also becomes active.

Example captured after launching Codex build 3437:

%CPU   PID   %MEM     RSS      COMMAND
125.7  29702 34.0     8549776  /usr/libexec/syspolicyd
11.3   29728 3.0      756064   /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
11.1   29701 1.9      471728   /Applications/Codex.app/Contents/MacOS/Codex
6.5    29699 0.1      16800    /usr/libexec/trustd

User-visible Gatekeeper dialog

The user repeatedly sees:

"Codex Computer Use" is damaged and can't be opened.
You should move it to the Trash.
This file was downloaded on an unknown date.

The app named in the dialog is:

/Users/mgair/.codex/computer-use/Codex Computer Use.app

Important verification

The affected helper app does not appear to be actually corrupt. It was checked locally:

codesign verification: valid on disk
Developer ID: OpenAI OpCo, LLC
TeamIdentifier: 2DC432GLL2
Notarization ticket: stapled

cmux.app, another unrelated notarized app, is accepted by Gatekeeper when syspolicyd is not wedged:

/Applications/cmux.app: accepted
source=Notarized Developer ID

This suggests the issue is not a generally unsigned or damaged app problem. It looks like syspolicyd enters a bad state after Codex Desktop starts.

Reproduction steps

  1. Boot macOS normally.

  2. Ensure Codex Desktop is closed.

  3. Observe Activity Monitor: CPU is normal.

  4. Run:

    sudo killall -9 syspolicyd trustd

  5. Confirm CPU is still normal.

  6. Open Codex Desktop.

  7. Observe syspolicyd rising to very high CPU and memory usage.

The same pattern was observed after manually replacing Codex with the latest freshly downloaded DMG build.

Workarounds attempted

1. Increase open file limit

The system maxfiles limit was increased:

This did not fix the issue.

2. Disable Codex Computer Use / Browser / hotkey hooks in user config

Current config state:

notify = []

[plugins."browser@openai-bundled"]
enabled = false

Current keybindings:

Current global hotkey state:

"globalDictationToggleHotkey": null
"appshotHotkey": null

The config files were temporarily protected from silent rewrites using uchg.

Despite this, after launching Codex Desktop, these processes still appeared:

/Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
/Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/.../SkyComputerUseClient turn-ended --previous-notify []

This suggests Codex Desktop may be launching Codex Computer Use outside the user-visible config path, or the desktop process may have a separate internal integration path.

3. In-app update

The in-app Sparkle update previously failed:

SUSparkleErrorDomain Code=4005
"An error occurred while starting the installer. Please try again later."

Manual DMG replacement succeeded, but did not resolve the issue.

Additional concern

One stale SkyComputerUseClient turn-ended process was observed with a very large serialized conversation payload in its command-line arguments. That command line appeared to include extensive thread context. This may be relevant if the helper is being repeatedly assessed or launched with very large arguments.

For privacy, the full command line is not included here, but it was clearly visible in pgrep -alf output.

Expected behavior

Opening Codex Desktop should not cause:

  • syspolicyd to consume 100-200% CPU.
  • syspolicyd to grow to multi-GB memory use.
  • Gatekeeper to show "Codex Computer Use" is damaged.
  • unrelated notarized apps to become hard to open while syspolicyd is wedged.

Actual behavior

Codex launch reliably causes syspolicyd and sometimes trustd to spike. Closing Codex and killing syspolicyd / trustd calms the system. Reopening Codex reproduces the issue.

User impact

This caused hours of troubleshooting, repeated reboots including Safe Mode attempts, broken/blocked app launches while syspolicyd was wedged, and significant Codex usage spent diagnosing the Codex Desktop bug itself.

Update: Reinstall / macOS 26.5.1 Did Not Fix It

The user reinstalled/updated macOS and retested.

Current system after reinstall/update:

macOS: 26.5.1
Build: 25F80
Codex Desktop: 26.527.60818
Codex build: 3437

Result: the issue still reproduces.

Before launching Codex, fileproviderd was already using high CPU, likely due to iCloud/File Provider resync after the reinstall. However, syspolicyd spiked specifically after Codex was launched.

Example after launching Codex on macOS 26.5.1:

%CPU   PID   %MEM     RSS      COMMAND
106.3  668   4.6      1164208  /usr/libexec/syspolicyd
89.7   1190  0.5      120336   /System/Library/PrivateFrameworks/FileProvider.framework/Support/fileproviderd
11.4   2827  1.9      488912   /Applications/Codex.app/Contents/MacOS/Codex
7.0    601   0.1      19808    /usr/libexec/trustd
0.0    3097  0.5      114592   /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

Important: the Codex config files still showed:

notify = []
Browser plugin disabled
keybindings = []
globalDictationToggleHotkey = null
appshotHotkey = null
config files protected with uchg

Despite that, Codex Desktop still launched:

/Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

Additional observation on macOS 26.5.1: the syspolicyd CPU usage is not just a short startup spike. It can drop temporarily and then rise again. One later sample showed:

%CPU   PID   %MEM     RSS      ELAPSED  COMMAND
181.6  668   7.4      1858064  19:03    /usr/libexec/syspolicyd

At that later point, the SkyComputerUseService process was no longer visible in the process list, but syspolicyd was still consuming very high CPU. This suggests the system policy loop may continue after the helper process exits or disappears.

Conclusion after this update: the issue is unlikely to be local corruption of Gatekeeper/SystemPolicy databases. It appears to be a reproducible Codex Desktop/macOS 26.5.x integration problem, and Codex Desktop appears to launch Codex Computer Use even when the visible user config disables the related hooks.

Request

Please escalate this to the Codex Desktop/macOS team.

Please also consider a goodwill account credit, usage refund, or temporary upgrade for the affected user, since substantial paid usage was consumed diagnosing what appears to be a Codex Desktop/macOS integration bug rather than the user's requested work.

Suggested account-facing wording:

I spent substantial paid Codex usage diagnosing a reproducible Codex Desktop bug on macOS where launching Codex causes syspolicyd/trustd CPU and memory runaway. Please consider restoring the consumed usage or providing a temporary upgrade/credit while this is investigated.

Attachments / useful local file

Detailed local troubleshooting notes:

/Users/mgair/Documents/New project/Codex_Gatekeeper_Workaround_2026-06-01.md