›_ Codex Issues
Codex Issues / #18975

Codex Desktop: Computer Use approval denied via MCP elicitation for Chrome in a new thread, and no approval prompt appears

Resolved 💬 4 comments Opened Apr 22, 2026 by Kinoo0 Closed Apr 22, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.417.41555 (1858)

What subscription do you have?

Pro

What platform is your computer?

macOS, Codex Desktop

What issue are you seeing?

Computer Use cannot control Google Chrome and immediately fails with:

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

No usable approval prompt appears in Codex, and macOS does not show a Google Chrome entry under Privacy & Security -> Automation.

Accessibility permission for Codex is already enabled. I also enabled the other relevant permissions I could find, but the approval flow for Chrome never appears.

What steps can reproduce the bug?

  1. Open Codex Desktop on macOS.
  2. Start a thread and ask @Computer Use to inspect or control Google Chrome.
  3. Keep Google Chrome running.
  4. The tool call fails immediately with:

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

  1. No approval prompt appears in Codex, and no Chrome entry appears in macOS Automation settings.

What is the expected behavior?

Codex Desktop should trigger a usable approval flow for Computer Use to access/control Google Chrome, or preserve/recover that approval state correctly.

Additional information

  • Codex config shows the bundled Computer Use plugin is enabled.
  • In local session logs, the failed thread records only the immediate denial.
  • In older logs from a previously working setup, I can see approval/permission-notification related entries, but in the failing runs there is no visible approval request being triggered.
  • This looks related to issue #18522, but in my case I observed the same symptom on April 22, 2026 with Codex Desktop 26.417.41555 (1858).

Local evidence

Codex config:

  • ~/.codex/config.toml has:

``toml
[plugins."computer-use@openai-bundled"]
enabled = true
``

Relevant local files/logs:

  • Session log:

~/.codex/sessions/2026/04/22/rollout-2026-04-22T17-33-01-019db489-2c7c-7652-a049-7179473f9d0c.jsonl

  • Desktop logs:

~/Library/Logs/com.openai.codex/2026/04/22/...
~/Library/Logs/com.openai.codex/2026/04/17/...

Observed behavior:

  • failing runs: immediate denial, no visible approval request
  • earlier working logs: approval / permission-notification events existed

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.

  • ##18896
  • ##18522

Powered by Codex Action

m13v · 4 months ago

hit this exact TCC dead end on a mac agent project earlier this year. chrome's row under Automation only materializes after the parent process actually fires its first apple event, so if the MCP layer denies the call before AESendMessage leaves the binary, TCC never sees a request and never prompts. matches your pattern of old logs showing prompts then nothing. usually means codex.app's codesign identity changed between builds, orphaning the existing TCC entry and silently blocking new prompts. try tccutil reset AppleEvents com.google.Chrome then tccutil reset AppleEvents com.openai.codex and relaunch.

Kinoo0 · 4 months ago

@m13v That was exactly it, thank you. Resetting AppleEvents for Chrome and Codex fixed it after relaunching and retrying from a fresh thread. Really appreciate the pointer.

bfernando · 4 months ago

yeah opening a new chat/thread after doing this worked. It still doesn't work in a previous chat/thread