Skip to content

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

Open
Open
Codex Desktop: Computer Use approval denied in old/resumed threads after restart, while new threads can authorize normally#18522
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-usemcpIssues related to the use of model context protocol (MCP) serverssessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@smartlau83
smartlau83
opened on Apr 19, 2026

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?

  1. Open a Codex Desktop thread.
  2. Use Computer Use successfully in that thread, e.g. inspect Google Chrome.
  3. Restart Codex Desktop.
  4. Return to the old thread.
  5. Ask Codex to inspect Chrome with Computer Use.
  6. Observe that the tool returns approval denied via MCP elicitation.
  7. Create a new thread and ask the same Computer Use request.
  8. 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.

Activity

  1. smartlau83
    added
    appIssues related to the Codex desktop app
    on Apr 19, 2026
  2. github-actions
    added
    bugSomething isn't working
    mcpIssues related to the use of model context protocol (MCP) servers
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Apr 19, 2026

  3. github-actions commented on Apr 19, 2026

    @github-actions
    github-actionsBot
    on Apr 19, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. mustbeasaltyfish commented on Apr 20, 2026

    @mustbeasaltyfish
    mustbeasaltyfish
    on Apr 20, 2026

    Facing the same problem, plz fix the bug 😭

  5. tomato-ga commented on Apr 20, 2026

    @tomato-ga
    tomato-ga
    on Apr 20, 2026

    yes, same problem

  6. exileskim commented on Apr 21, 2026

    @exileskim
    exileskim
    on Apr 21, 2026

    Same issue

  7. likakuli commented on Apr 21, 2026

    @likakuli
    likakuli
    on Apr 21, 2026

    same issue

  8. cromiem commented on Apr 21, 2026

    @cromiem
    cromiem
    on Apr 21, 2026

    same issue

  9. AlchemyDing commented on Apr 21, 2026

    @AlchemyDing
    AlchemyDing
    on Apr 21, 2026

    same issue

  10. RickAi commented on Apr 22, 2026

    @RickAi
    RickAi
    on Apr 22, 2026

    same issue

  11. Hanosn2007 commented on Apr 22, 2026

    @Hanosn2007
    Hanosn2007
    on Apr 22, 2026

    一样的问题

  12. bfernando commented on Apr 22, 2026

    @bfernando
    bfernando
    on Apr 22, 2026

    i have teh same issue too

  13. mrseth commented on Apr 22, 2026

    @mrseth
    mrseth
    on Apr 22, 2026

    same issue

  14. DanielJD1216 commented on Apr 23, 2026

    @DanielJD1216
    DanielJD1216
    on Apr 23, 2026

    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

  15. Lancardo commented on Apr 26, 2026

    @Lancardo
    Lancardo
    on Apr 26, 2026 – with ChatGPT Codex Connector

    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.
  16. etraut-openai
    added
    computer-use
    on May 3, 2026

  17. IgorGanapolsky commented on May 14, 2026

    @IgorGanapolsky
    IgorGanapolsky
    on May 14, 2026

    "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.

  18. maxanatsko commented on Aug 12, 2026

    @maxanatsko
    maxanatsko
    on Aug 12, 2026

    Additional reproduction suggesting this is broader than Computer Use:

    • Codex Desktop on Windows ARM64
    • A third-party MCP server sent a standard form-mode elicitation/create request with one required boolean field
    • The response completed as Decline after 37 ms
    • No prompt was rendered or actionable
    • The behavior occurred in an old/resumed task, before and after restarting Desktop

    This appears consistent with a resumed-task elicitation routing or session-state failure, but it is not specific to app authorization or the Computer Use plugin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcomputer-usemcpIssues related to the use of model context protocol (MCP) serverssessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions