Codex Desktop: Computer Use approval denied in old/resumed threads after restart, while new threads can authorize normally

Open 💬 14 comments Opened Apr 19, 2026 by smartlau83

💡 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.415.40636 (1799)

What subscription do you have?

Pro for $200

What platform is your computer?

macOS 26.4.1, Codex Desktop

What issue are you seeing?

After restarting Codex Desktop, old/resumed threads can no longer use Computer Use for app state access. Calls such as get_app_state for Chrome, Excel, or Word fail immediately with:

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

Newly created threads can trigger Computer Use authorization and use Chrome/Word/Excel normally, so this does not appear to be a macOS Accessibility/Screen Recording permission issue or a missing plugin installation issue.

What steps can reproduce the bug?

Open a Codex Desktop thread.
Use Computer Use successfully in that thread, e.g. inspect Google Chrome.
Restart Codex Desktop.
Return to the old thread.
Ask Codex to inspect Chrome with Computer Use.
Observe that the tool returns approval denied via MCP elicitation.
Create a new thread and ask the same Computer Use request.
Observe that the new thread can use Computer Use successfully.

What is the expected behavior?

Old/resumed threads should either preserve the previous Computer Use approval state or re-trigger the app authorization prompt.

Additional information

Actual behavior

Old/resumed threads fail immediately with MCP elicitation approval denied. No usable reauthorization prompt appears.

Additional local evidence

The Computer Use plugin is enabled in ~/.codex/config.toml:

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

The Computer Use client exposes only:

mcp
turn-ended

No public reset/authorize/grant command was found.

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 3 months ago

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

#15508

Powered by Codex Action

mustbeasaltyfish · 3 months ago

Facing the same problem, plz fix the bug 😭

tomato-ga · 3 months ago

yes, same problem

exileskim · 3 months ago

Same issue

likakuli · 3 months ago

same issue

cromiem · 3 months ago

same issue

AlchemyDing · 3 months ago

same issue

RickAi · 2 months ago

same issue

Hanosn2007 · 2 months ago

一样的问题

bfernando · 2 months ago

i have teh same issue too

mrseth · 2 months ago

same issue

DanielJD1216 · 2 months ago

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

Lancardo · 2 months ago

Adding another reproduction case with a slightly different pattern.

Environment:

Codex Desktop, macOS
Date/time observed: 2026-04-26, Asia/Shanghai
Computer Use CUA App Version shown in tool output: 758

Observed behavior in the same Codex thread:

list_apps succeeds and lists many apps, including Chrome, Finder, VS Code, Notes, MATLAB_R2026a, and Zotero.
get_app_state("org.zotero.zotero") succeeds and returns a full UI tree.
get_app_state("com.google.Chrome") fails with:

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

get_app_state("com.mathworks.matlab") fails with:

Computer Use approval denied via MCP elicitation for app 'com.mathworks.matlab'.

get_app_state("com.microsoft.VSCode") fails with:

Computer Use approval denied via MCP elicitation for app 'com.microsoft.VSCode'.

get_app_state("com.apple.finder") and get_app_state("com.apple.Notes") also fail with the same approval-denied pattern.
get_app_state("com.openai.codex") returns a separate safety-policy denial, which appears expected.

Local checks:

The affected apps are installed under /Applications.
Bundle identifiers verified from app Info.plist:
com.mathworks.matlab
com.google.Chrome
com.microsoft.VSCode
org.zotero.zotero

Why this seems like the same issue:

macOS Accessibility/Screen Recording permissions are unlikely to be the root cause, because Computer Use can fully inspect Zotero in the same session.
The failure appears to be in the Computer Use MCP elicitation/app authorization layer: one app remains allowed, while other user-requested apps are immediately denied without a usable reauthorization prompt.

IgorGanapolsky · 2 months ago

"Old threads denied, new threads authorize" is a classic session-state mismatch — the resumed thread's stored MCP authorization token references a Codex runtime identity (or CODEX_HOME) that doesn't match the current process after restart. New threads succeed because they re-elicit fresh; resumed threads can't because the stored auth doesn't apply anymore.

# Check if you have multiple Codex homes / runtimes:
printenv | grep -i codex
ls -la ~/.codex ~/Library/Application\ Support/Codex 2>/dev/null
# And inspect the actual stored thread state for one of the denied threads:
codex thread show <thread-id> --json 2>&1 | grep -E "mcp_auth|codex_home|process_id" 2>&1 | head -10

If you have more than one CODEX_HOME (or one that was reassigned between sessions), the resumed thread is trying to authorize against the old home. Fix is to consolidate to one canonical CODEX_HOME, or invalidate the old auth tokens in the stored thread state.

This belongs under the multiple-Codex-homes and session-reuse failure classes — I documented six root causes for "Computer Use authorization issues": https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html

Free script (scripts/self-diagnose.mjs) captures both home layouts + env into a redacted bundle. $19 quick read confirms whether stored thread state is the trigger or there's a second cause.