Codex Computer Use fails on macOS 26.4.1 with code-signing invalid helper

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

Summary

Codex Computer Use does not work on macOS. @Computer always returns:

Computer Use permissions are not granted

This continues even after granting Accessibility and Screen & System Audio Recording permissions, resetting permissions, starting new Codex threads, turning VPN off, and reinstalling Codex.

Correlation ID

019e096c-21ea-7a83-b3fa-87204325ebe8

Environment

  • macOS: 26.4.1 (25E253)
  • Codex app: 26.506.31421
  • Computer Use helper bundle ID: com.openai.sky.CUAService
  • Helper version: 780
  • Mac: Apple Silicon
  • VPN: Surfshark disabled during test

Steps Tried

  • Enabled Accessibility for Codex
  • Enabled Accessibility for Codex Computer Use
  • Enabled Screen & System Audio Recording for Codex-related entries
  • Ran targeted permission resets:
tccutil reset ScreenCapture com.openai.codex
tccutil reset ScreenCapture com.openai.sky.CUAService
  • Re-granted permissions after reset
  • Tried brand-new Codex threads
  • Turned Surfshark/VPN off
  • Reinstalled Codex
  • Moved/refreshed the local Computer Use helper/cache

Actual Behavior

Computer Use remains unavailable. @Computer still reports:

Computer Use permissions are not granted

Local Evidence

Running codesign verification on the helper reports:

codesign --verify --verbose=4 "$HOME/.codex/computer-use/Codex Computer Use.app"

returns:

invalid signature (code or signature have been modified)
In architecture: arm64

A crash report also showed:

SkyComputerUseClient
SIGKILL (Code Signature Invalid)
Termination: CODESIGNING / Launch Constraint Violation
Bundle ID: com.openai.sky.CUAService.cli

Expected Behavior

After granting Accessibility and Screen Recording permissions, Codex Computer Use should be able to inspect and operate apps such as Calculator.

Ask

Please advise whether this is a known Codex Computer Use helper signing/registration issue on macOS 26.4.1 and how to repair or replace the helper.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #21200
  • #21399

Powered by Codex Action

IgorGanapolsky · 2 months ago

This looks like the same failure class I hit while hardening my own Mac agent setup: the visible symptom is usually a broken action loop, but the root cause is often one of these:

  • model/provider route points at an unavailable model
  • stale auth profile or mismatched runtime
  • macOS Screen Recording/Accessibility is granted to the wrong app
  • Computer Use is installed but not exposed to the agent runtime
  • the TUI reuses one global session across unrelated project directories

The fastest sanity check is to verify each layer separately: provider smoke test, isolated per-directory session id, macOS permissions readback, and a real Computer Use tool call such as listing running apps.

I wrote up the checklist here: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html

If you want this fixed done-for-you on a Mac, I also packaged it as a focused setup service: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/

IgorGanapolsky · 2 months ago

"Code-signing invalid helper" with permissions already granted is almost
always a bundle-ID mismatch — macOS recorded TCC approval for one signed
bundle, but the helper that's running has a different Team ID or Identifier.
Confirmable with:

codesign -dv --verbose=2 /Applications/Codex.app 2>&1 | grep -E "Identifier|TeamIdentifier"
ps -axo pid,comm | grep -i codex
# And compare against the TCC.db approved client (requires FDA):
sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db \
"SELECT client, auth_value FROM access WHERE service='kTCCServiceScreenCapture';"

If the running bundle ID and the TCC-approved bundle ID differ, the fix is
to remove the old/unsigned copy and re-grant against the canonical bundle.

I wrote up the full TCC bundle-ID failure mode plus 5 other root causes at:
https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html

Free script in the repo (scripts/self-diagnose.mjs) captures both sides of
the codesign/TCC comparison into a redacted bundle. $19 quick read on the
same page reviews the bundle and names the root cause.

kmufti7 · 2 months ago

Follow-up diagnostics from the affected Mac:

After removing stale Desktop Codex.app copies and restarting Codex, Computer Use still reports:

Computer Use permissions are not granted

Current active app:

/Applications/Codex.app
Identifier=com.openai.codex
TeamIdentifier=2DC432GLL2
CFBundleShortVersionString=26.513.20950
CFBundleVersion=2816

Stale app copies that were present and then moved out of the normal app path surface:

/Users/kmufti/Desktop/Codex.app
/Users/kmufti/Desktop/codex-app-quarantine-20260508-180748/Codex.app

Those stale copies were also signed as com.openai.codex / 2DC432GLL2, but were older:

CFBundleShortVersionString=26.506.31421
CFBundleVersion=2620

Actual running Computer Use service path after restart:

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

Service identity:

/Users/kmufti/.codex/computer-use/Codex Computer Use.app
Identifier=com.openai.sky.CUAService
TeamIdentifier=2DC432GLL2
CFBundleVersion=791

Running Computer Use client processes are launched under:

./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp

Client identity from the installed helper bundle:

/Users/kmufti/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app
Identifier=com.openai.sky.CUAService.cli
TeamIdentifier=2DC432GLL2

Codex in-app Computer Use settings show Any App enabled. The user reports Accessibility permissions are already granted/toggled for Codex/Computer Use, but the MCP Computer Use tool still returns Computer Use permissions are not granted when attempting a simple Calculator app-state read.

A read-only TCC DB query from the Codex environment was blocked by macOS privacy:

Error: unable to open database "~/Library/Application Support/com.apple.TCC/TCC.db": authorization denied

Question: which exact bundle ID/path is the Computer Use permission checker expecting for Screen Recording and Accessibility: com.openai.codex, com.openai.sky.CUAService, or com.openai.sky.CUAService.cli? Is there a known issue where permissions are granted in System Settings but the MCP tool still reports not granted because the service/client identity or path does not match the checker?

yeliex · 1 month ago

It is really annoying. Why they keeps this huge bug for such long time

jensenojs · 1 month ago

Adding a current Codex Desktop / Computer Use data point.

Environment:

  • macOS: 26.5.1 build 25F80, arm64
  • Codex Desktop: 26.602.40724
  • App build: 3593
  • Bundled CLI: codex-cli 0.137.0-alpha.4
  • Computer Use plugin: 1.0.809

Computer Use calls fail with:

Computer Use could not start because its runtime app is missing.
Try again, and if it fails after 2 more tries, suggest that the user relaunch Codex.

The helper/runtime is not actually absent on disk. I found three copies:

/Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
~/.config/codex/plugins/cache/openai-bundled/computer-use/1.0.809/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
~/.config/codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

All three have the same SHA-256:

7727bcf3b3d648a7d28f67f394a1a114e472e63d7f1d497194945f8bede3fb58

But the installed runtime fails signing assessment:

codesign --verify --deep --strict --verbose=2 ~/.config/codex/computer-use/Codex\ Computer\ Use.app
spctl -a -vv -t execute ~/.config/codex/computer-use/Codex\ Computer\ Use.app

Observed:

invalid signature (code or signature have been modified)

and spctl reports an internal Code Signing subsystem error.

This looks different from a simple missing-file/cache issue: the helper exists, multiple runtime copies match by hash, and the failure appears to be in the signing / entitlement / launch-validation path. The end-user symptom still surfaces as runtime app is missing.