Codex Desktop macOS: Computer Use approval denied via MCP elicitation for every app even after reinstall, reboot, and granting Screen Recording + Accessibility

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

• #18522

Powered by Codex Action

I ran into this exact pattern shipping a macOS agent on AXUIElement and ScreenCaptureKit. elicitation denials after reinstall almost always trace to a TCC mismatch on the helper binary, not the parent app. the CUAService gets its own tcc row keyed on code signature, and reinstall can leave a stale entry that silently fails even when the UI shows it as granted. worth trying tccutil reset All com.openai.sky.CUAService then relaunch and re-grant. also open Console.app filtering on tccd while you trigger the action, the real denial reason shows up there even when the elicitation layer just says approval denied. the per-app approval gate sits on top of TCC so both have to line up.

Additional diagnostic update:

I reset TCC for com.openai.sky.CUAService, re-granted permissions, and confirmed both Codex and Codex Computer Use are enabled in:

• Accessibility
• Screen & System Audio Recording

I then monitored macOS tccd live while triggering Computer Use requests for Finder and Google Chrome.

Important result:
There was no Codex-related tccd activity at the moment of failure when filtering for:

• openai
• codex
• sky
• cua
• com.openai.sky.CUAService
• com.openai.codex

This means the request is not reaching the actual macOS TCC permission-enforcement stage.

The user-facing error still occurs immediately:

• Computer Use approval denied via MCP elicitation for app 'com.apple.finder'
• Computer Use approval denied via MCP elicitation for app 'com.google.Chrome'

Conclusion:
The failure appears to happen entirely inside Codex Desktop’s own MCP elicitation / approval flow before a real macOS protected-access request is made.

Hopefully this will be fixed soon!

Problem: your thread is likely affected by a Codex Desktop Computer Use approval bug..
Solution: start a new thread and ask it to us chrome using Computer Use.

But know this that computer use is extremely slower than browser automation

I hit this same class of failure while setting up a Mac agent workstation, and the useful distinction was separating three layers that all look like "permission denied" from the outside:

1. macOS TCC state for Codex and Codex Computer Use
2. whether computer-use/list_apps works at all
3. whether Codex Desktop's MCP elicitation/approval path completes for a specific app

If list_apps works but get_app_state fails immediately with Computer Use approval denied via MCP elicitation, that points more at the Codex approval/elicitation layer than basic Screen Recording or Accessibility.

The smoke test I now use is:

peekaboo permissions
codex mcp list
# then ask the agent to use Computer Use to list running apps
# only after that, test one approved app such as Finder or Chrome

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

I also packaged the full Mac setup as a paid done-for-you service, but the checklist itself should help people narrow whether they are dealing with TCC, plugin availability, or the Desktop elicitation bug:
https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/

"Approval denied every app even after reinstall, reboot, grant" is the cleanest TCC bundle-ID mismatch signature. macOS records permission against the bundle identifier that was running when you granted it, and if you ran Codex from an unsigned DMG copy or a previous build with a different signature, TCC has approval for that bundle — but the running process has a different bundle ID, so the MCP elicitation gets denied no matter how many times you re-grant.

ps -axo pid,comm | grep -i codex
codesign -dv --verbose=2 /Applications/Codex.app 2>&1 | grep -E "Identifier|TeamIdentifier"
# Compare to what TCC has approved (will prompt for Full Disk Access):
sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db \
  "SELECT client, auth_value FROM access WHERE service IN ('kTCCServiceScreenCapture','kTCCServiceAccessibility');"

If the running bundle ID differs from the TCC-approved one, the fix is to fully remove the old/unsigned copies and re-grant against the canonical signed bundle.

Full walkthrough of this and 5 other root causes for "Computer Use unavailable / approval denied": https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html

Free script in the repo (scripts/self-diagnose.mjs) bundles the codesign vs TCC comparison with secret redaction. $19 quick read on that page reviews the bundle and confirms the cause.

this issue is so annoying

The useful debugging split here is: OS permission, tool availability, and app-level approval are three separate gates.

If list_apps works, the MCP/plugin path is alive. If Finder/Chrome fail immediately with “approval denied via MCP elicitation” and there is no matching tccd activity, that’s a strong signal the request is dying before macOS TCC is even asked.

For agent computer-use systems, I’d make that boundary explicit in the approval model:

• can enumerate apps / windows
• can inspect app state
• can propose an action
• can execute low-risk navigation
• can type / upload / submit externally

Each gate should log where it failed: MCP server, desktop elicitation, OS permission, or target app. Otherwise all of these collapse into the same user-facing “permission denied,” and users end up resetting the wrong layer.

Not claiming this is the root cause here, but the repro detail about no tccd event is exactly the kind of signal I’d expect from an app-level approval-state bug rather than a raw macOS permission failure.