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

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.