Codex Chrome extension's extension-host helper saturates syspolicyd, freezing system-wide app launches (macOS Apple Silicon)

Open 💬 2 comments Opened Jun 13, 2026 by xiqijia

What version of the Codex App are you using?

Codex App 26.609.41114 (CFBundleVersion 3888).

What platform is your computer?

macOS on Apple Silicon / arm64.

System details observed locally:

Darwin MacBook-Pro.local 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 20:38:56 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6000 arm64

What issue are you seeing?

After setting up a Chrome browser-automation / computer-use feature in Codex, my Mac entered a state where most applications could not launch while a few already-running/cached apps still worked. The system log was flooded with:

syspolicyd  failed to call driver: 0x3
syspolicyd  Failed to generate SecStaticCode for <private> error: 100024

This was accompanied by fileproviderd / iCloud churn, including BRCloudDocsErrorDomain:140 messages.

Root cause I traced:

The culprit was a Codex-installed Chrome extension, extension ID hehggadaopoacecdllhhajmbjkdcmajg, whose native host kept being relaunched by Chrome:

/Users/<me>/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-host chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/

The process tree confirmed the parent was Google Chrome itself: the extension-host process's PPID resolved to /Applications/Google Chrome.app, whose PPID was launchd / 1. In other words, Chrome repeatedly re-execs this extension-host helper. Each exec appears to trigger a full Gatekeeper/SystemPolicy validation because the bundled helper is not signed/notarized in a way syspolicyd can cache. This saturates syspolicyd until it can no longer generate SecStaticCode for other apps, which is why unrelated apps fail to launch system-wide.

Killing the child PID was not useful because Chrome immediately spawned a new one with a different PID.

This looks like the same class of problem as #25882, #19885, #16767, #25719, and #20283.

Steps to reproduce

  1. On macOS Apple Silicon, enable Codex's Chrome browser-automation / computer-use feature. This installs the extension plus ~/.codex/plugins/cache/openai-bundled/chrome/.../extension-host.
  2. Use Chrome normally with the extension active.
  3. Observe syspolicyd and trustd climb. log show --predicate 'process == "syspolicyd"' floods with failed to call driver / Failed to generate SecStaticCode error: 100024.
  4. Try to open other apps. Many fail to launch.

Workaround that fixed it

rm -rf ~/.codex/plugins/cache/openai-bundled/chrome

Then remove the extension hehggadaopoacecdllhhajmbjkdcmajg from chrome://extensions, run:

pkill -9 -if '\.codex/'

and reboot.

Expected behavior

The bundled extension-host should be a properly Developer-ID-signed, notarized, hardened-runtime binary so syspolicyd can cache its validation and does not re-verify it on every exec. Codex browser automation should not be able to wedge system-wide app launching on macOS.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗