MCP OAuth reauth succeeds but active session still uses stale refresh token (invalid_grant)

[vinzenz]

Summary

After re-authenticating an OAuth-enabled MCP server, the currently running Codex agent/session can continue using a stale refresh token and still fail MCP initialization with invalid_grant until the app/session is restarted.

Expected behavior

After successful codex mcp login <server>, MCP handshakes in the active session should use fresh credentials immediately (or the runtime should force re-init of auth state).

Observed behavior

• codex mcp login <server> reports success.
• MCP tool calls in the same running session continue failing with:
  OAuth token refresh failed: invalid_grant: Invalid or expired refresh token
• Restarting the app/new session clears the issue.

Steps to reproduce

1. Configure any OAuth-enabled MCP server.
2. Let its refresh token become invalid/expired.
3. In a running Codex session, trigger MCP usage and observe invalid_grant failure.
4. Run codex mcp login <server> and complete OAuth successfully.
5. Retry MCP usage in the same running session.
6. Observe continued invalid_grant until restart/new session.

Environment

• Codex CLI: codex-cli 0.107.0
• Platform: macOS 26.3.1 (25D2128)
• Date observed: 2026-03-10

Notes

This appears to be runtime credential cache invalidation rather than OAuth login failure. A post-login cache refresh or MCP client reinitialization would likely resolve it.

[github-actions]

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

• Notion MCP stuck after refresh token invalid_grant; Codex Desktop doesn't prompt re-auth #13956
• Supabase MCP repeatedly requires reauthentication: OAuth token refresh failed during initialize #13852

Powered by Codex Action

[strobil]

Adding another data point for a private Sourcegraph Cloud MCP server.

Environment:

• Codex CLI: codex-cli 0.128.0
• MCP server: streamable_http, OAuth
• URL: https://<redacted>.sourcegraphcloud.com/.api/mcp

Observed pattern:

• Right after restarting Codex, the MCP server works (list_repos, keyword_search).
• After Codex has been running for a while, the MCP session can get stuck until re-auth/restart.

Captured failure from the same MCP config:

resources/list failed: failed to get client: MCP startup failed: handshaking with MCP server failed: Send message error Transport [...] error: Auth error: OAuth token refresh failed: Server returned error response: invalid_grant: The provided authorization grant [...] or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. The refresh token is malformed or not valid., when send initialize request

I also checked the current rust-v0.128.0 source. My read is:

• OAuthPersistor::refresh_if_needed() exists and calls AuthorizationManager.refresh_token() before MCP operations: https://github.com/openai/codex/blob/rust-v0.128.0/codex-rs/rmcp-client/src/oauth.rs#L346-L368
• refresh failure is only logged in refresh_oauth_if_needed(); the operation can continue with stale auth state: https://github.com/openai/codex/blob/rust-v0.128.0/codex-rs/rmcp-client/src/rmcp_client.rs#L681-L687
• Streamable HTTP recovery handles 404 session expiry, while the test suite explicitly asserts 401 does not trigger recovery: https://github.com/openai/codex/blob/rust-v0.128.0/codex-rs/rmcp-client/tests/streamable_http_recovery.rs#L28-L45

This looks consistent with this issue and #17265: preemptive refresh exists, but invalid_grant / 401 does not force MCP client reinit, clear stale auth state, or prompt re-login for the active session.