Computer Use MCP denies Chrome approval after TCC reset and app restart

Open 💬 4 comments Opened Apr 23, 2026 by todayslibera-dev

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug Report: Computer Use MCP denies Chrome approval after TCC reset and app restart

Summary

Computer Use in Codex App consistently fails before interacting with Google Chrome:

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

This started suddenly around 2026-04-22/2026-04-23. The same Computer Use flow reportedly worked a few days earlier. Restarting Codex completely multiple times and resetting macOS TCC permissions did not resolve it.

Environment

macOS: 15.6.1 (Build 24G90)
Codex App bundle id: com.openai.codex
Codex App version: 26.417.41555
Codex App build: 1858
Computer Use helper bundle id: com.openai.sky.CUAService
Computer Use helper version: 1.0
Computer Use helper build: 755
Codex CLI: codex-cli 0.122.0
oh-my-codex: v0.14.2
Node.js: v22.19.0
Platform: darwin arm64
Target app: Google Chrome, bundle id com.google.Chrome

Reproduction Steps

Start Codex App.
Ensure Google Chrome is open.
Trigger Computer Use from Codex against Google Chrome, for example:

get_app_state({"app":"Google Chrome"})

Observe the failure:

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

Expected Behavior

Computer Use should request or reuse the proper permission and return Chrome window state/screenshot/accessibility tree, or show a user-actionable permission prompt.

Actual Behavior

Computer Use immediately returns:

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

No usable Chrome state is returned. Repeating the call produces the same failure.

Troubleshooting Already Tried

The user already fully quit and relaunched Codex App multiple times.

TCC reset was run successfully for both Codex App and the Computer Use helper:

tccutil reset Accessibility com.openai.codex
tccutil reset AppleEvents com.openai.codex
tccutil reset ScreenCapture com.openai.codex
tccutil reset Accessibility com.openai.sky.CUAService
tccutil reset AppleEvents com.openai.sky.CUAService
tccutil reset ScreenCapture com.openai.sky.CUAService

All commands returned success:

Successfully reset Accessibility approval status for com.openai.codex
Successfully reset Accessibility approval status for com.openai.sky.CUAService
Successfully reset AppleEvents approval status for com.openai.codex
Successfully reset AppleEvents approval status for com.openai.sky.CUAService
Successfully reset ScreenCapture approval status for com.openai.codex
Successfully reset ScreenCapture approval status for com.openai.sky.CUAService

After the reset and multiple Codex restarts, Computer Use still returned the same error.

Important Diagnostic Detail

Direct AppleEvents from the shell can still query Chrome successfully:

osascript -e 'tell application "Google Chrome" to get URL of active tab of front window'

Result:

http://localhost:7357/

This suggests Chrome automation is not globally blocked at the OS level. The failure appears specific to the Codex Computer Use MCP approval/elicitation path or the com.openai.sky.CUAService helper approval flow.

Process State Observed

Codex App and Computer Use helper were running:

/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp

Impact

Computer Use is unusable for Chrome-based runtime smoke tests. This blocks browser-based validation from Codex App even though ordinary shell-level AppleEvents to Chrome still work.

Request

Please investigate whether:

Computer Use MCP app approval/elicitation state can get stuck in a denied state independent of macOS TCC.
com.openai.sky.CUAService needs additional reset/permission handling after Codex App updates.
The error should surface a user-actionable recovery step instead of just approval denied via MCP elicitation.

If there is an internal state file/cache that stores the denied elicitation result, please provide the supported way to reset it.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

#18975
#18896
#18522

Powered by Codex Action

IgorGanapolsky · 3 months ago

This repro is useful because it rules out a common false lead: if shell-level AppleEvents can query Chrome but Computer Use still fails with approval denied via MCP elicitation, the issue is probably not "Chrome automation is globally blocked."

The fastest diagnostic split I found on my own Mac:

# 1. OS permission readback
peekaboo permissions

# 2. MCP/plugin availability
codex mcp list

# 3. Agent-level smoke test
# Ask the agent to use Computer Use to list running apps only.

# 4. App-specific approval test
# Then ask for Finder or Chrome state.

If step 3 works but step 4 fails, the failure is likely in the app-specific approval/elicitation path rather than the raw Computer Use helper startup.

I wrote the checklist here in case it helps other people triage the same Mac setup failure:
https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html

I also offer a paid done-for-you Mac setup for OpenClaw/Codex/Computer Use, but the important bit for this issue is the diagnostic split above:
https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/

IgorGanapolsky · 3 months ago

"Denied after TCC reset and restart" usually means TCC re-recorded approval against the wrong bundle identifier. tccutil reset clears the table, but the next approval prompt records permission for whatever bundle ID is running at that moment — and if you have multiple Codex copies (DMG, App Store, Homebrew, signed dev build), the running bundle may not match the bundle TCC is checking on subsequent invocations.

# Which bundle is actually running right now:
ps -axo pid,comm | grep -i codex
codesign -dv --verbose=2 /Applications/Codex.app 2>&1 | grep -E "Identifier|TeamIdentifier"
# Find any other Codex copies on the disk:
mdfind "kMDItemKind == 'Application' && kMDItemDisplayName == 'Codex*'"
# After resetting, confirm what TCC recorded (requires FDA):
sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db \
  "SELECT client, auth_value FROM access WHERE service='kTCCServiceScreenCapture';"

If mdfind returns multiple Codex.app paths, remove all but the canonical signed one, tccutil reset Accessibility com.openai.codex && tccutil reset ScreenCapture com.openai.codex, then re-launch and re-grant — TCC will record the canonical bundle.

Full walkthrough of the TCC bundle-ID failure mode + 5 other root causes for "approval denied / Computer Use unavailable": https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html

Free script in the repo (scripts/self-diagnose.mjs) captures the codesign + running-bundle + TCC posture comparison into a redacted bundle. $19 quick read on that page confirms the root cause.

elophanto · 2 months ago

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 direct AppleEvents can query Chrome, macOS hasn’t globally blocked browser automation. If Chrome state still fails only through Computer Use, the likely failure is the app-specific elicitation/approval state between the client and helper.

A good recovery UI would probably show those as separate checks:

helper running
OS permissions granted to the exact signed bundle
MCP server reachable
app-specific approval prompt available/not cached denied
supported reset path for that approval cache

Right now “approval denied via MCP elicitation” collapses all of that into one error, which sends users into TCC resets even when TCC is not the failing layer.