Codex Desktop does not refresh OAuth-backed MCP access token before startup; keeps sending expired bearer from Keychain

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

• #25903

Powered by Codex Action

I can corroborate this from a Windows Codex Desktop setup with an OAuth-backed Streamable HTTP MCP server that supports Dynamic Client Registration and refresh-token rotation.

Sanitized reproduction/evidence:

• MCP server: OAuth/DCR-backed Streamable HTTP endpoint.
• The OAuth discovery metadata advertises a token_endpoint, grant_types_supported includes refresh_token, token_endpoint_auth_methods_supported includes none, and scopes include offline refresh capability.
• Codex stores an MCP OAuth credential entry with access_token, refresh_token, client_id, expires_at, scopes, server name, and server URL.
• A direct grant_type=refresh_token request to the advertised token endpoint succeeds and returns a rotated access_token, rotated refresh_token, and expires_in.
• A direct raw MCP JSON-RPC initialize request using the refreshed access token succeeds with HTTP 200 and returns server info.
• However, the running Codex Desktop MCP worker can still return Auth required after external refresh/login, which suggests the worker either does not always refresh before initialize, does not recover reactively from 401/AuthRequired, or does not update its in-memory Authorization state after the credential cache changes.

The code appears to have part of the intended mechanism already:

• codex-rs/rmcp-client/src/oauth.rs has OAuthPersistor::refresh_if_needed() and persists rotated tokens via persist_if_needed().
• codex-rs/app-server/src/mcp_refresh.rs can queue RefreshMcpServers for active threads.

The remaining product gap seems to be one or both of these:

1. Before startup/tool discovery/initialize, expired or near-expired OAuth credentials are not reliably refreshed for the worker that will send the MCP initialize request.
2. After a 401/AuthRequired response, Codex does not reliably perform a single refresh-token recovery, atomically persist the rotated token set, update the live worker Authorization state, and retry initialize/tool call once before asking for browser OAuth.

Desired behavior:

• If a stored refresh token is present and valid, Codex should refresh without browser OAuth when the access token is expired/near-expired or when initialize/tool call returns 401/AuthRequired/invalid_token.
• Refresh-token rotation should update access_token, refresh_token, and expires_at atomically in the configured credential store.
• The running MCP worker should update its in-memory Authorization header/state after refresh, not require a Desktop/thread restart to pick up the credential change.
• If refresh fails with invalid_grant or equivalent, only then prompt browser OAuth/reconnect.
• Logging should distinguish: expired access token preflight refresh, reactive 401 refresh, invalid refresh token, server auth failure, and worker/cache mismatch.

Useful tests would cover:

• startup with expired access token and valid refresh token refreshes before initialize;
• initialize returns 401 invalid_token, refresh succeeds, initialize is retried once;
• rotated refresh token is persisted and used for the next refresh;
• invalid refresh token surfaces reauth rather than looping;
• concurrent MCP requests single-flight refresh rather than racing token rotation;
• active Desktop/thread worker uses refreshed credentials without requiring a new chat or app restart.

This is especially important for unattended/overnight agents using OAuth-backed MCP servers where daily browser reauth defeats the purpose of storing refresh tokens.

Additional sanitized reproduction, in case it helps narrow this down. This looks like the same failure mode, but on Linux with mcp_oauth_credentials_store = "file" and Atlassian Rovo MCP rather than macOS Keychain.

Environment

• Product/runtime: Codex CLI
• Version: codex-cli 0.141.0
• OS: Linux x86_64, Ubuntu 24.04 family, hostname redacted
• MCP credential store: mcp_oauth_credentials_store = "file"
• MCP server: Atlassian Rovo MCP, Streamable HTTP
• MCP URL: https://mcp.atlassian.com/v1/mcp/authv2
• codex mcp list --json reports this server as OAuth-backed:

{
  "name": "atlassian",
  "enabled": true,
  "transport": "streamable_http",
  "url": "https://mcp.atlassian.com/v1/mcp/authv2",
  "auth_status": "o_auth",
  "startup_timeout_sec": null,
  "tool_timeout_sec": null
}

Timeline

1. Fresh Codex startup failed with:

MCP client for `atlassian` failed to start: MCP startup failed: handshaking with MCP server failed:
  Send message 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, when send initialize request

MCP startup incomplete (failed: atlassian)

1. The user then manually ran codex mcp login atlassian. The credential file was updated and Codex could treat the server as configured/authenticated again.
2. After the newly issued access token expired, a later fresh Codex startup failed again with the same OAuth authorization required, when send initialize request error.

Sanitized credential state after manual login

No token values included. The stored credential contained exactly one Atlassian entry.

{
  "credentials_file_mode": "600",
  "credentials_file_mtime_iso": "2026-06-25T06:01:27.374Z",
  "atlassian_entry_count": 1,
  "server_name": "atlassian",
  "server_url": "https://mcp.atlassian.com/v1/mcp/authv2",
  "access_token_present": true,
  "refresh_token_present": true,
  "stored_expires_at_iso": "2026-06-25T14:01:27.368Z",
  "scopes_count": 21,
  "scopes_include_offline_access": true,
  "access_iat_iso": "2026-06-25T06:01:27.000Z",
  "access_exp_iso": "2026-06-25T14:01:27.000Z",
  "access_expired_at_next_failure": true,
  "access_issuer": "https://auth.atlassian.com",
  "access_type": "ACCESS",
  "refresh_iat_iso": "2026-06-25T06:01:27.000Z",
  "refresh_exp_iso": "2026-09-23T06:01:27.000Z",
  "refresh_expired_at_next_failure": false,
  "refresh_issuer": "https://auth.atlassian.com",
  "refresh_type": "ROTATING_REFRESH"
}

Atlassian OAuth metadata checks

Unauthenticated request to the MCP endpoint returns a proper Bearer challenge with resource metadata:

HTTP/2 401
www-authenticate: Bearer resource_metadata="https://mcp.atlassian.com/.well-known/oauth-protected-resource/v1/mcp/authv2", error="invalid_token", error_description="Missing or invalid access token"

Protected resource metadata also matches the configured resource and advertises offline_access:

{
  "resource": "https://mcp.atlassian.com/v1/mcp/authv2",
  "authorization_servers_count": 1,
  "bearer_methods_supported": ["header"],
  "scopes_include_offline_access": true,
  "scopes_include_read_jira_work": true,
  "scopes_include_write_jira_work": true
}

The advertised authorization server metadata includes a token endpoint and refresh_token grant support:

{
  "issuer": "https://auth.atlassian.com",
  "token_endpoint_present": true,
  "registration_endpoint_present": true,
  "grant_types_supported": [
    "authorization_code",
    "client_credentials",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:token-revoke",
    "urn:ietf:params:oauth:grant-type:jwt-bearer",
    "urn:ietf:params:oauth:grant-type:token-exchange"
  ]
}

Interpretation

This does not appear to be specific to macOS Keychain. In this reproduction:

• Codex recognizes the MCP server as OAuth-backed (auth_status: "o_auth").
• File-backed MCP OAuth credentials are present and readable.
• The access token is expired at the next failure.
• The refresh token is still present and unexpired.
• The server advertises offline_access, a token endpoint, and refresh_token grant support.
• Manual codex mcp login atlassian temporarily fixes the issue until the access token expires again.

I did not manually exchange the stored refresh token because Atlassian uses a rotating refresh token and I did not want to mutate the user's credential state while collecting diagnostics.

Based on the above, this looks consistent with Codex not refreshing the stored OAuth-backed Streamable HTTP MCP access token before startup/tool discovery, or not retrying initialize with a refreshed token after invalid_token.

This is not a duplicate. I'm seeing it on ubuntu with the latest codex cli.

Have this on OpenAI Codex (v0.143.0)

This happens a lot

╭───────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.145.0)                    │
│                                               │
│ model:     gpt-5.6-sol low   /model to change │
│ directory: ~/dev/sandboxes/CodexBar           │
╰───────────────────────────────────────────────╯

  Tip: New Use /fast to enable our fastest inference with increased plan usage.

⚠ MCP client for `atlassian` failed to start: MCP startup failed: failed to refresh OAuth tokens for server atlassian: OAuth token refresh failed:
  Server returned error response: unauthorized_client: refresh_token is invalid

⚠ MCP startup incomplete (failed: atlassian)

My claude does not log out this much, but codex does all the time. It's very annoying.

Additional current reproduction for Atlassian Rovo MCP.

Environment

• Codex CLI: codex-cli 0.147.0
• Platform: Rocky Linux 8.10, Linux x86_64
• MCP transport: Streamable HTTP with OAuth
• MCP URL: https://mcp.atlassian.com/v1/mcp/authv2
• Multiple concurrent Codex sessions share the default keyring

Observed behavior

codex mcp login atlassian restores access temporarily. After the access token expires, Codex requests reauthorization. The Codex logs contain:

MCP OAuth provider refresh failed
OAuth token refresh failed: Server returned error response: unauthorized_client: refresh_token is invalid

The same failure occurs with Codex CLI 0.145.0 and 0.147.0. Immediately before the provider error, the logs report successful loading of the Atlassian credential from Codex MCP Credentials. The current CLI also uses the shared MCP OAuth transaction lock and rereads the authoritative credential store before refreshing.

Expected behavior

Concurrent Codex sessions should refresh the shared Atlassian OAuth credentials and continue operating without daily browser reauthorization. Rotated credentials should update active MCP clients or trigger a clean MCP reconnect.

No OAuth token values or private credentials are included here.