Skip to content

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

Open

Description

@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.

Activity

  1. michaellee8 commented on Jul 7, 2026

    @michaellee8

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

  2. openjay commented on Jul 22, 2026

    @openjay

    For anyone hitting this via the Chrome extension-host path: the underlying daemon-side exhaustion is being tracked with more data in #27662 (#27662 (comment)). 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions