Codex does not auto-refresh routed MCP OAuth tokens even when a refresh token is stored

[infoseekAI]

What issue are you seeing?

Summary

Codex persists a refresh_token for a routed MCP server in ~/.codex/.credentials.json, but it does not automatically refresh the access token when the token expires.

As a result, once the access token expires:

• MCP tool calls start failing with auth errors
• automations and later runs break
• the only recovery is manual CLI login and browser reauth

This defeats the purpose of storing a refresh token.

Environment

• Product: Codex desktop / Codex MCP client. MacOS 26.3.1 (a)
• Date observed: April 9, 2026

Expected behavior

If Codex has a valid stored refresh_token for the MCP server, it should automatically refresh the expired access token and continue making authenticated MCP calls without requiring manual CLI login.

This is especially important for:

• automations
• recurring background runs
• later thread/tool invocations after some idle time

Actual behavior

When the access token expires, Codex starts returning auth failures instead of using the stored refresh token to recover automatically.

Observed failure:

{"success": false, "error": "invalid_grant", "msg": "Authorization required"}


### What steps can reproduce the bug?

- Auth to MCP, observe the credentials and refresh token stored in credentials.json
- Wait for the token expiry, access the MCP again (prior to refresh token expiry), it will fail on auth and not automatically refresh as it should
- Use the CLI to authenticate manually, it will then work again

### What is the expected behavior?

Within the refresh token expiry window re-auth should be automatic

### Additional information

_No response_

[github-actions]

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

• Error loading configuration: Your access token could not be refreshed because your refresh token was already used. Please log out and sign in again #15754
• Codex CLI auth.json copy flow is broken: refresh succeeds but session still rejected (docs misleading) #15502

Powered by Codex Action

[infoseekAI]

Yes. In practical terms, OAuth-backed MCPs are dead in Codex right now.

Not because provider auth is broken, but because Codex’s built-in MCP execution path is failing to use valid stored OAuth credentials. The proof is already clear:

codex mcp login succeeds
/Users/xyz/.codex/.credentials.json contains valid tokens
direct refresh works
direct authenticated MCP calls work
built-in MCP tool calls still return 401 oauth_required
So from the user’s perspective, the result is the same: any MCP that depends on OAuth is unusable in Codex until that runtime layer is fixed.

[ankitvg]

Adding a concrete datapoint that seems related but more specific than token refresh:

In my environment, Codex App (macOS) appears to send MCP requests using a token issued to the ChatGPT OAuth client, not the Codex OAuth client.

What I observed:

• I connected the same MCP server (stewreads.com) from both ChatGPT app and Codex app.
• Codex app creates its own OAuth client during setup.
• But server logs show Codex app requests carrying token claims (client_id / aud) for the ChatGPT client.

Control test:

• I ran Codex CLI inside the Codex app terminal against the same MCP server.
• Codex CLI used the correct Codex client-issued token.
• So this seems specific to Codex App’s built-in MCP runtime path, not Codex CLI.

Repro:

1. Connect MCP server in ChatGPT app and complete OAuth.
2. Connect same MCP server in Codex app and complete OAuth.
3. Invoke MCP tools from Codex app.
4. Inspect token claims in MCP server logs: client_id/aud maps to ChatGPT client.
5. Run Codex CLI against same server and compare: client_id/aud maps correctly to Codex client.

Expected:

• Codex App should use only Codex client-issued tokens (app/client-scoped credential isolation).

Actual:

• Codex App appears to reuse ChatGPT client token for the same MCP server identity.

[Cyanoth]

We run a few MCP Servers and our users are reporting the same with the codex desktop app (both windows & mac)

In the Codex desktop app, MCP servers authenticated via OAuth stop working after the access token expires. The app appears to keep using the expired access token for the current chat instead of refreshing it with the refresh token.
Starting a new chat restores functionality, and manually restarting the MCP server also restores it temporarily. The Codex CLI does not have this issue & handles token refresh correctly.

Codex Desktop App (Version 26.415.30602 (1773))
MCP Auth type: OAuth Token lifetime: access token = 1 hour, refresh token = 30 days

Steps to reproduce

1. Add an MCP server authenticated via OAuth to Codex.
2. Complete the OAuth flow to obtain a valid access token and refresh token.
3. In the Codex desktop app, use the MCP server successfully in a chat.
4. Wait until the access token expires.
5. In the same chat, send another request that uses the same MCP server.

Actual result

1. The MCP server responds with error: Auth required.
2. The desktop app appears to continue using the expired access token.
3. Retrying in the same chat does not recover authentication.
4. Starting a new chat makes the MCP server work again.
5. This suggests the existing chat session does not trigger token refresh or pick up refreshed auth state.

Expected result

When the access token expires, the desktop app should automatically refresh it using the OAuth refresh token and continue making MCP requests seamlessly.
This is the behavior currently observed in codex CLI.

Workaround

In the Codex desktop app:
Go to Settings -> MCP Servers -> Toggle the affected MCP server off and on. Click the Restart button

After restarting, MCP calls work again in the chat, but only until the access token expires again.

Impact

This breaks long-lived chats that rely on OAuth-authenticated MCP servers. Users must either start a new chat or manually restart the server after token expiry.

[technotablet]

I presume Codex v0.128.0 no longer has this issue.

I was able to login to the MCP server (todoist), continued the same codex session but with a 3-4 hour inactivity (the access token typically expires in 1 hour), and also started a fresh session the next day. All cases that never worked earlier worked this time.

[amiranvarov]

i'm on v0.128.0, and it still has this issue

[dsghi]

I’m seeing what appears to be the same issue in Codex Desktop on Windows, with server-side evidence from an OAuth-enabled MCP server.

Related: #14144

Summary

Codex Desktop sessions appear to retain per-session MCP OAuth refresh-token state. When multiple Codex sessions use the same OAuth MCP server, one session may rotate the refresh token chain forward while an older session later resumes and presents a refresh token from several generations back.

The older session then fails all MCP operations with generic errors until the MCP server is disabled/re-enabled or the session/app is restarted.

Environment

• Product: Codex Desktop on Windows 26.429.61741
• MCP auth: OAuth / Dynamic Client Registration
• Access token lifetime: 10 minutes
• Refresh token lifetime: 30 days
• Server behavior: refresh tokens rotate on use
• Server mitigation already tried: a 5-minute idempotent replay marker for the immediately previous refresh token

Server-side Evidence

The MCP server logs short SHA-256 fingerprints of refresh tokens, not token material.

Successful refresh chain for the same Codex MCP client ID:

19:18  a577bd5762f9 -> 2c038f3caf9e
19:27  2c038f3caf9e -> cf1e044b93dc
19:39  cf1e044b93dc -> 432dc8317a97
19:48  432dc8317a97 -> 70a8eba10384

Then an older/stale Codex session attempted MCP calls:

19:55  rejected reason=missing refreshTokenFingerprint=2c038f3caf9e

That token had been valid at 19:27 but was already multiple generations behind by 19:55. Because it was not the immediately previous token, the server’s replay window could not recover it.

The stale session then repeatedly failed reads/searches/writes with invalid_grant, while another Codex session in the same desktop app instance could still read/write successfully.

Why This Looks Codex-Side

• The MCP server is healthy and accepts current refresh tokens.
• A different Codex session in the same app instance can continue to use the MCP server successfully.
• The failing session presents an older refresh token generation instead of the latest one.
• Starting/switching sessions can temporarily restore functionality, but older sessions later fail after the access token's expiry.
• The behavior matches the report in MCP OAuth reauth succeeds but active session still uses stale refresh token (invalid_grant) #14144: active sessions continue using stale refresh credentials.

Expected Behavior

When one Codex session refreshes an OAuth MCP token, other sessions using the same MCP server should either:

• read the latest app-level credential state before attempting refresh, or
• invalidate/reload their per-session MCP auth cache, or
• recover cleanly after invalid_grant by reloading the current credential state / prompting reauth.

Actual Behavior

Older sessions continue to present stale refresh tokens and surface generic MCP failures.

Suggested Fix Area

Codex Desktop’s MCP OAuth runtime likely needs shared credential synchronization or cache invalidation across sessions/chats for the same MCP server. Refresh-token rotation makes stale per-session credential copies invalid by design.

[w00ing]

Adding another datapoint that matches this issue, with Mixpanel's hosted MCP server.

Environment:

Codex CLI: codex-cli 0.130.0
Platform: macOS 26.3.1 (a), Darwin 25.3.0 arm64
MCP server: mixpanel, streamable_http, https://mcp.mixpanel.com/mcp
Credential store: macOS Keychain item Codex MCP Credentials, not a local .mcp-auth directory
Observed on 2026-05-12:

• codex mcp login mixpanel had previously succeeded.
• The stored MCP OAuth payload contained both access_token and refresh_token.
• The stored token response had expires_in: 86400; local expires_at indicated the access token should still have been valid.
• A direct MCP initialize request using the stored access token returned 401 invalid_token from Mixpanel. The error description said the bearer token was invalid, expired, or no longer recognized, and recommended clearing/reconnecting MCP client auth.
• A direct OAuth refresh-token request to Mixpanel succeeded using the stored refresh_token and returned a fresh access token plus a fresh refresh token.
• The freshly refreshed access token then succeeded against the same Mixpanel MCP initialize request with 200 OK.
• Running codex mcp login mixpanel again restored the stored Keychain credential and MCP access temporarily.

So in this case the provider-side refresh path appears healthy: the refresh token was present and usable, and the refreshed access token worked. The failure mode is that Codex continued with an invalid/stale MCP access token instead of using the stored refresh token and updating the persisted rotated credential. This also looks sensitive to refresh-token rotation, since the refresh response includes a new refresh token.