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.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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:
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/
"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.
Follow-up diagnostics from the affected Mac:
After removing stale Desktop
Codex.appcopies and restarting Codex, Computer Use still reports:Current active app:
Stale app copies that were present and then moved out of the normal app path surface:
Those stale copies were also signed as
com.openai.codex/2DC432GLL2, but were older:Actual running Computer Use service path after restart:
Service identity:
Running Computer Use client processes are launched under:
Client identity from the installed helper bundle:
Codex in-app Computer Use settings show
Any Appenabled. The user reports Accessibility permissions are already granted/toggled for Codex/Computer Use, but the MCP Computer Use tool still returnsComputer Use permissions are not grantedwhen attempting a simple Calculator app-state read.A read-only TCC DB query from the Codex environment was blocked by macOS privacy:
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, orcom.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?It is really annoying. Why they keeps this huge bug for such long time
Adding a current Codex Desktop / Computer Use data point.
Environment:
26.5.1build25F80,arm6426.602.407243593codex-cli 0.137.0-alpha.41.0.809Computer Use calls fail with:
The helper/runtime is not actually absent on disk. I found three copies:
All three have the same SHA-256:
But the installed runtime fails signing assessment:
Observed:
and
spctlreports 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.