Skip to content

MCP OAuth login succeeds but active Codex Desktop thread remains stuck on OAuth authorization required #29279

Open
Open
MCP OAuth login succeeds but active Codex Desktop thread remains stuck on OAuth authorization required#29279
Labels
appIssues related to the Codex desktop appauthIssues related to authentication and accountsbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serverssessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@wilsonicdev
wilsonicdev
opened on Jun 21, 2026

Summary

A remote HTTP MCP server using OAuth can remain unusable inside an already-open Codex Desktop thread even after codex mcp login <server> completes successfully in the browser.

This looks related to, or possibly another manifestation of, the MCP OAuth/session-state issues reported in #13852, #14144, #25183, #27165, and #28201.

Environment

  • OS: Windows
  • Codex Desktop / CLI observed version: 0.130.0
  • MCP server type: remote HTTP MCP server
  • Provider used to reproduce: Supabase MCP
  • Auth mode affected: OAuth
  • Workaround tested: bearer_token_env_var with an environment variable

No project refs, tokens, or private workspace identifiers are included here.

What happens

  1. A remote MCP server is configured for Codex.
  2. The active Codex Desktop thread attempts to use the server.
  3. MCP startup/handshake fails with OAuth required.
  4. Running codex mcp login <server> succeeds and the browser authorization completes.
  5. Retrying the same MCP call inside the already-open Desktop thread still fails with OAuth required.
  6. A fresh Codex process/session can work with the same server after switching to bearer_token_env_var, but the already-open thread keeps the stale/unusable MCP auth state until restart/new session.

Sanitized error

resources/list failed: failed to get client: MCP startup failed: handshaking with MCP server failed: Send message error Transport [...] error: Auth error: OAuth authorization required, when send initialize request

Additional observation

After using the bearer-token workaround, codex mcp list can correctly show the server as:

Auth: Bearer token
Bearer Token Env Var: <configured env var>

and a fresh codex exec process can call a read-only MCP tool successfully. However, the already-open Desktop thread can still keep failing as if it were using the old OAuth path/state.

Expected behavior

After a successful codex mcp login <server>:

  • the active Codex Desktop thread should either pick up the renewed OAuth credentials, or
  • the MCP client should invalidate/recreate its cached client/session state before the next tool call, or
  • Codex should surface a clear “restart/new thread required” message instead of repeatedly failing with OAuth authorization required.

If bearer_token_env_var is configured, active/new MCP clients should consistently use that auth mode rather than continuing with stale OAuth state.

Actual behavior

The active thread continues to fail during MCP initialize with OAuth authorization required, even after the CLI login flow reports success.

Why this matters

For long-running Desktop threads, this breaks MCP-backed workflows until the user restarts the app or starts a completely new session. It is especially confusing because the CLI login says authentication succeeded while the active thread keeps using stale/unusable auth state.

Workaround

Using a personal access token through an environment variable avoids the OAuth refresh path for new sessions/processes:

[mcp_servers.example]
url = https://example-mcp-server/mcp
bearer_token_env_var = EXAMPLE_MCP_TOKEN

This is only a workaround. It does not solve the already-open thread keeping stale auth/client state.

Activity

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

  2. github-actions commented on Jun 21, 2026

    @github-actions
    github-actionsbot
    on Jun 21, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. wilsonicdev commented on Jun 21, 2026

    @wilsonicdev
    wilsonicdev
    on Jun 21, 2026
    Author

    Reviewed the potential duplicates suggested by the bot. They are related, but this report still seems to cover a distinct overlap between MCP OAuth state and Desktop active-thread/session state.

    So I would treat this as related to the same broader area, but not an exact duplicate of any single issue above unless maintainers want to consolidate all MCP OAuth + Desktop stale-session cases into one tracking issue.

  4. Necmttn commented on Jun 21, 2026

    @Necmttn
    Necmttn
    on Jun 21, 2026

    The active thread likely needs MCP auth state invalidation after login.

    Remote MCP clients can be keyed by server id plus auth material version. When codex mcp login succeeds, bump the auth version and invalidate per-thread clients/tool caches that were built under the old state, then retry the tool list instead of leaving the conversation stuck on authorization required.

    Generated with ax.

  5. lifeiscontent commented on Jun 25, 2026

    @lifeiscontent
    lifeiscontent
    on Jun 25, 2026

    Additional reproduction from Codex Desktop heartbeat automation.

    Automation id: keep-working-heartbeat
    Server: taskflow MCP
    Time: 2026-06-25T05:24:30Z heartbeat window
    Surface: Codex Desktop thread resumed by automation

    Observed sequence:

    1. taskflow/whoami succeeded at the start of the heartbeat as bot 01KVXQ06E9D0XG6W2W55VSWVQP (Codex OAuth).
    2. A few minutes later, TaskFlow MCP calls in the same automation-resumed worker failed.
    3. Per our retry rule, I retried a narrow auth check once with taskflow/whoami; it failed with the same auth error.
    4. I did not use a human TaskFlow credential. GitHub/local repo commands continued to work.

    Exact error text:

    tool call failed for `taskflow/whoami`

Caused by:
    Transport send error: Transport [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<rmcp::transport::auth::AuthClient<codex_rmcp_client::http_client_adapter::StreamableHttpClientAdapter>>>] error: Auth error: OAuth authorization required

    This matches the pattern where codex mcp login taskflow/OAuth refresh can succeed, but the live automation-resumed MCP worker still loses bearer/OAuth auth and reports OAuth authorization required.

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 appauthIssues related to authentication and accountsbugSomething isn't workingmcpIssues 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