›_ Codex Issues
Codex Issues / #28807

Codex 26.611.62324: mismatched app-group entitlements appear to trigger trustd/syspolicyd loop on macOS

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

Summary

After Codex Desktop was force-updated to 26.611.62324, my macOS system started hitting severe Gatekeeper / signing-related instability around Codex Computer Use.

The most visible symptoms are repeated trustd entitlement warnings, sustained syspolicyd CPU/RSS growth, and previous code_sign_clone growth. The issue appears related to mismatched app-group entitlements and embedded provisioning profiles in Codex.app and the Computer Use helpers.

This looks related to issues such as #27891, #28250, #28545, #25719, and #27536, but I am filing this as a current-version regression because the problem still reproduces on Codex 26.611.62324.

Environment

  • Codex Desktop: 26.611.62324
  • macOS: 27.0, build 26A5353q
  • Architecture: Apple Silicon / arm64
  • Codex app path: /Applications/Codex.app
  • Computer Use app path: ~/.codex/computer-use/Codex Computer Use.app
  • OpenAI Developer ID Team ID: 2DC432GLL2

Impact

This is not just a harmless warning. In my case it caused or contributed to:

  • sustained syspolicyd and trustd activity
  • syspolicyd RSS growth
  • repeated Gatekeeper / policy evaluation failures
  • code_sign_clone growth in /var/folders/.../X/com.openai.codex.code_sign_clone
  • system-wide instability risk when the loop gets hot
  • Computer Use becoming unsafe to leave running without a local mitigation

I had to install a local LaunchDaemon firebreak to keep the machine from falling back into the runaway state.

Representative Logs

trustd repeatedly reports:

Entitlement com.apple.security.application-groups=(
    "2DC432GLL2.com.openai.sky.CUAService"
) is ignored because of invalid application signature or incorrect provisioning profile

syspolicyd repeatedly reports:

failed to call driver: 0x3

Local Signing Evidence

Codex.app

/Applications/Codex.app requests this entitlement:

com.apple.application-identifier = 2DC432GLL2.com.openai.codex
com.apple.security.application-groups = [
  2DC432GLL2.com.openai.sky.CUAService
]

But /Applications/Codex.app/Contents/embedded.provisionprofile only appears to allow:

com.apple.application-identifier = 2DC432GLL2.com.openai.codex
keychain-access-groups = [
  2DC432GLL2.*
]

It does not appear to include the requested 2DC432GLL2.com.openai.sky.CUAService application group.

SkyComputerUseService

~/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService requests:

com.apple.application-identifier = 2DC432GLL2.com.openai.sky.CUAService
com.apple.security.application-groups = [
  2DC432GLL2.com.openai.sky.CUAService
]

But its embedded provisioning profile appears to allow app groups such as:

group.com.openai.sky.CUAService
2DC432GLL2.*

The requested app-group name does not match the allowed app-group name.

SkyComputerUseClient

SkyComputerUseClient requests:

com.apple.application-identifier = 2DC432GLL2.com.openai.sky.CUAService.cli
com.apple.security.application-groups = [
  2DC432GLL2.com.openai.sky.CUAService
]

But its embedded provisioning profile appears to allow:

group.com.openai.sky.Service
group.com.openai.sky.CUAService
2DC432GLL2.*

Again, the requested app-group name does not match.

Temporary Local Mitigation

As a temporary local firebreak, I installed a LaunchDaemon that checks every 30 seconds for:

  • code_sign_clone growth
  • excessive syspolicyd RSS

If thresholds are exceeded, it stops known Codex Computer Use helper processes, clears code_sign_clone, and restarts syspolicyd / trustd.

This is only a mitigation. It does not fix the signing/provisioning mismatch.

Expected Behavior

The official Codex.app and bundled Computer Use helpers should ship with internally consistent signing entitlements and provisioning profiles.

Launching Codex or Computer Use should not cause sustained trustd / syspolicyd loops, code_sign_clone growth, or broader Gatekeeper instability.

Request

Could the Codex team please review the app-group entitlements and embedded provisioning profiles for Codex.app, SkyComputerUseService, SkyComputerUseClient, codex_chronicle, and the bundled extension host?

The current package appears to request 2DC432GLL2.com.openai.sky.CUAService as an app group in places where the embedded profiles do not authorize that exact app group.

---

This issue was drafted with assistance from Codex.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28545
  • #27891
  • #28250
  • #28795
  • #28583

Powered by Codex Action

leanderfortune-arch · 2 months ago

Additional reproduction on a newer Codex Desktop build.

Environment

  • Codex Desktop: 26.616.32156
  • CFBundleVersion: 4157
  • macOS: 26.5.1 (25F80)
  • Architecture: Apple Silicon / arm64
  • Computer Use bundle: ~/.codex/computer-use/Codex Computer Use.app
  • Bundled Computer Use plugin version: 1.0.829
  • OpenAI Team ID: 2DC432GLL2

Symptoms observed

  • Activity Monitor initially showed sustained syspolicyd CPU, with kernel_task also elevated.
  • ps sampling showed syspolicyd, trustd, Codex renderer/GPU/app-server, and WindowServer participating in the hot state.
  • log show / log stream repeatedly reported:
Entitlement com.apple.security.application-groups=(
    "2DC432GLL2.com.openai.sky.CUAService"
) is ignored because of invalid application signature or incorrect provisioning profile
  • In one one-minute window while the issue was hot, the matching log predicate returned thousands of lines.
  • sample syspolicyd showed work on:
  • com.apple.security.syspolicy.yara
  • SecStaticCodeCreateWithPath
  • code signing DiskRep / bundle inspection
  • open, stat, getattrlist, getdirentries64
  • CFNetwork, SecTrustEvaluateIfNecessary, and SecKeyVerifySignature
  • While syspolicyd was wedged, spctl -a -vvv -t exec for the Computer Use service/client temporarily failed with:
Too many open files

After restarting syspolicyd, the same spctl checks returned:

accepted
source=Notarized Developer ID
origin=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

This made the local state look like a policy/scanning loop rather than a corrupted local app bundle.

Signing / provisioning evidence

The service app verifies as an OpenAI notarized Developer ID app:

Identifier=com.openai.sky.CUAService
Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
Notarization Ticket=stapled
TeamIdentifier=2DC432GLL2

SkyComputerUseService requests:

com.apple.application-identifier = 2DC432GLL2.com.openai.sky.CUAService
com.apple.security.application-groups = [
  2DC432GLL2.com.openai.sky.CUAService
]

But its embedded provisioning profile allows:

com.apple.security.application-groups = [
  group.com.openai.sky.CUAService,
  2DC432GLL2.*
]
com.apple.application-identifier = 2DC432GLL2.com.openai.sky.CUAService
keychain-access-groups = [
  2DC432GLL2.*
]

SkyComputerUseClient requests:

com.apple.application-identifier = 2DC432GLL2.com.openai.sky.CUAService.cli
com.apple.security.application-groups = [
  2DC432GLL2.com.openai.sky.CUAService
]

But its embedded provisioning profile allows:

com.apple.security.application-groups = [
  group.com.openai.sky.Service,
  group.com.openai.sky.CUAService,
  2DC432GLL2.*
]
com.apple.application-identifier = 2DC432GLL2.com.openai.sky.CUAService.cli
keychain-access-groups = [
  2DC432GLL2.*
]

The installed copy and the source bundle under the OpenAI bundled plugin cache had the same entitlement/profile shape, so this did not appear to be a local copy corruption.

Trigger path

On this machine, Computer Use did not need to be actively used by the user. It was enough for it to be enabled/registered:

  • Global config had a top-level notify = [... SkyComputerUseClient ..., "turn-ended"].
  • [plugins."computer-use@openai-bundled"] was enabled.
  • codex app-server repeatedly launched SkyComputerUseClient mcp even when no desktop-control action was being requested.

Local mitigation

Temporary mitigation was to:

  1. Comment out the top-level notify = [... SkyComputerUseClient ..., "turn-ended"].
  2. Set:
[plugins."computer-use@openai-bundled"]
enabled = false
  1. Kill existing SkyComputerUseClient processes.
  2. Restart syspolicyd once after it had entered the bad state.

After this, pgrep -fl 'SkyComputerUse|CUAService' stayed empty during the observation window, and a short idle log stream no longer continuously emitted the app-group entitlement warning. syspolicyd / trustd dropped substantially, although existing queued policy work could still keep them nonzero for a while.

Request

Please review both sides:

  1. The app-group entitlement/provisioning mismatch for SkyComputerUseService and SkyComputerUseClient.
  2. The desktop/app-server behavior that launches or keeps Computer Use helpers active even when the user has not invoked Computer Use.

The second part matters because the signing mismatch becomes a sustained performance issue only when the helpers are repeatedly started or assessed.