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

Open 💬 3 comments Opened Jun 13, 2026 by xiqijia
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28071
  • #27662
  • #26795
  • #27136

Powered by Codex Action

michaellee8 · 1 month ago

observed the same thing on my macos as well, it was flagged as malware when rebooted

openjay · 1 month ago

For anyone hitting this via the Chrome extension-host path: the underlying daemon-side exhaustion is being tracked with more data in #27662 (https://github.com/openai/codex/issues/27662#issuecomment-5042147491). We've also published an MIT-licensed watchdog (evidence capture + auto-restart with cooldown) that works regardless of which app is doing the feeding: https://github.com/openjay/syspolicyd-watchdog