Repository navigation
MCP OAuth credential works in new chat but existing thread remains stuck on 401 #25183
Description
What version of Codex is running?
Codex Doctor reported v0.135.0-alpha.1 during the affected session.
Platform
Windows, Codex Desktop.
What issue are you seeing?
An OAuth MCP server can successfully authenticate through the CLI, and the same server works in a brand new Codex chat, but an existing Codex thread remains stuck returning 401: Reauthentication required for the same MCP tools.
This looks like the existing thread/session keeps stale unauthenticated MCP client state even after successful OAuth login and after restarting Codex Desktop.
Reproduction observed
- Start from an existing Codex Desktop thread where an OAuth MCP server is returning auth failures.
- Run MCP tool call in that thread.
- Result:
401: "Server returned 401: 'Reauthentication required'"
- Result:
- Run CLI OAuth login for the same server:
codex mcp login agent_app_platform_apps --scopes mcp.access- Result: CLI reports successful login.
- Retry the same MCP tool call in the original Desktop thread.
- Result: same
401.
- Result: same
- Force tool discovery again in the thread.
- Result: same
401.
- Result: same
- Open the built-in browser to see if that triggers a reauth flow.
- Result: same
401.
- Result: same
- Fully restart Codex Desktop and retry in the same thread.
- Result: same
401.
- Result: same
- Create a side conversation from the affected thread and retry.
- Result: same
401.
- Result: same
- Create a completely brand new chat and use the same OAuth MCP server.
- Result: works successfully.
Expected behavior
After successful codex mcp login, after a Desktop restart, or at least after fresh tool discovery, the existing thread should either:
- use the refreshed OAuth credential, or
- recreate the affected MCP client/session, or
- trigger a fresh interactive reauth flow.
A side conversation should not inherit a poisoned MCP auth/session state if the global OAuth credential is valid.
Actual behavior
The original thread and its side conversation continue to return:
401: "Server returned 401: 'Reauthentication required'"
A brand new chat works with the same MCP server and same saved credential state.
Why this seems distinct from general OAuth failure
The OAuth flow itself appears to work:
codex mcp login <server> --scopes mcp.accesssucceeds.- Dynamic client registration and authorization complete successfully.
- A fresh chat can use the MCP server afterward.
The failure appears isolated to the Desktop/thread MCP runtime consuming or refreshing credentials for an already-created thread/session.
Related issues
This appears related to the same family as:
- MCP auth/session does not refresh after successful browser login #21407
- Codex does not auto-refresh routed MCP OAuth tokens even when a refresh token is stored #17265
The detail that seems worth tracking separately is that a brand new chat works while the original thread and side conversation stay stuck, suggesting thread-scoped or conversation-scoped MCP client/session state is not being invalidated.
Activity
github-actions commentedon May 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
m13v commentedon May 30, 2026
the part that bit us here isn't the OAuth flow, it's that the MCP client caches its auth state at session creation, not per call.
codex mcp loginwrites a fresh credential to the global store, but the existing thread still holds a client object that bound its 401 on first connect. a brand new chat builds a new client against the refreshed token, so it works; the old thread never re-reads the store. the seam is session-scoped client lifecycle vs global credential lifecycle. restart doesn't fix it because session/load rehydrates the same poisoned client instead of rebuilding it. until login invalidates or recreates the per-thread MCP client, the side conversation inherits the same dead handle.