›_ Codex Issues
Codex Issues / #29279

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

Open 💬 4 comments Opened Jun 21, 2026 by wilsonicdev
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27799
  • #28201
  • #29160

Powered by Codex Action

wilsonicdev · 2 months ago

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.

  • #27799 is close on the MCP startup symptom: a saved OAuth credential appears valid when used directly, but Codex does not attach/read it during MCP initialize. This issue differs because here the CLI/fresh process can work after reconfiguration, while the already-open Desktop thread keeps failing with stale OAuth state.
  • #28201 is very relevant for Windows OAuth credential persistence/keyring behavior. However, that report is mainly about keyring-backed credentials not being found after restart. This issue also includes the active-thread behavior after re-login/reconfiguration, where the current Desktop thread continues using stale/unusable auth state while a fresh process can succeed.
  • #29160 is relevant for the Desktop session/config-staleness dimension: existing conversations do not pick up updated credentials/config. That issue is about model provider/API credentials rather than MCP OAuth, but it may share the same root class of bug: long-lived Desktop sessions caching credentials/client state without refreshing or invalidating it.
  • #27165 is also related to OAuth-backed MCP refresh behavior, especially expired access token vs valid refresh token. This issue is not only pre-startup refresh, though; it also covers the case where browser OAuth or a bearer-token workaround succeeds outside the current Desktop thread, but the active thread remains stuck until a restart/new session.

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.

Necmttn · 2 months ago

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

lifeiscontent · 2 months ago

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.