MCP OAuth tokens for HTTP servers not reliably reused across sessions — duplicate cache-key entries force repeated re-auth

[DaveHolden2025]

Describe the bug

For an HTTP-type MCP server that uses OAuth (PKCE, public client — clientSecret: null), Copilot CLI appears to mint a new token-cache entry under a different cache-key hash more often than expected, instead of finding and reusing the one still-valid cached token for that server.

Over about 3 weeks of normal use, I have 13 separate <hash>.tokens.json files in ~/.copilot/mcp-oauth-config/ that are all for the exact same server URL + OAuth scope, when I'd expect at most one entry that gets updated/refreshed in place. Only 1 matching <hash>.json client-registration file exists for that server, so the token-cache key and the client-registration key appear to diverge over time.

Two of the 13 token files were written in the same second and contain byte-identical expiresAt epoch values, which strongly suggests a single OAuth completion got persisted under two different cache-key hashes rather than one canonical entry being reused.

Separately (possibly independent, possibly compounding): none of the 13 cached tokens contain a refreshToken field — only accessToken + expiresAt. Observed access-token lifetime is consistently ~75–90 minutes. Since there's no refresh token, once it expires there is no silent-refresh path and the full interactive browser consent flow must run again. Combined with the cache-key issue above, the net effect looks like "the token expires in under an hour and I constantly have to re-authenticate," when it's really a mix of (a) a genuinely short-lived, non-refreshable token, and (b) the client sometimes failing to locate a still-valid cached token for the same server.

Affected version

1.0.80

Steps to reproduce the behavior

1. Configure an HTTP MCP server that requires OAuth (registered in ~/.copilot/mcp-config.json with "type": "http", pointing at a server behind an internal API gateway).
2. Authenticate once via the interactive browser flow.
3. Use the tool across multiple CLI sessions (including separate worktree-backed sessions) over several days.
4. Inspect ~/.copilot/mcp-oauth-config/*.tokens.json — instead of a single file per server updated in place, multiple files accumulate for the identical server URL/scope. Some have expiresAt values identical to the second with another file.
5. In practice this surfaces as being prompted to re-authenticate noticeably more often than the access token's actual ~75–90 minute lifetime would suggest, i.e. sessions don't always find/reuse an already-valid cached token.

Expected behavior

• A given MCP server's OAuth token cache entry should be looked up and updated using a single, stable cache key (e.g., derived only from server/resource URL + client ID), not one that can vary across otherwise-identical auth attempts for the same server.
• When a still-valid, non-expired cached token already exists for a server, any session should find and reuse it rather than triggering a fresh interactive login.
• If a variable value (such as the randomly chosen local loopback redirect port used during the OAuth flow) is unintentionally being folded into the persisted cache-key, that would explain the duplicate-key behavior observed above.

Additional context

• OS: Windows 11 (Windows_NT)
• MCP server type: http, OAuth with PKCE, public client
• Token cache directory (~/.copilot/mcp-oauth-config/) is per-user/global, not per-session, so in principle tokens should already be shareable across sessions/worktrees on the same machine — but the duplicate cache-key entries above show that reuse isn't happening reliably.
• Observed access-token lifetimes across 13 samples for the same server: consistently ~75–90 minutes.
• No refreshToken field present in any of the 13 cached token files for this server.
• Docs describe mcp-oauth-config/ as file-based storage used "when keychain-backed storage is unavailable." On this machine (Windows 11 with Credential Manager available) it may be worth confirming why the file-based fallback path is being used at all, since that could be related to the cache-key inconsistency.

[benrrr56-wq]

Two byte-identical expiresAt files written in the same second is a strong signal of a concurrency bug: two OAuth completions raced and each persisted its own cache entry under a different key, no CAS on the write. Beyond making the cache key stable (server URL + client id + scope, as you propose), I'd add a compare-and-swap on the token-cache write keyed by that stable hash so a concurrent completion updates the same entry rather than minting a new one. On the missing refreshToken: for a public client over PKCE that is unusual, most servers will issue one, so I'd confirm whether the server actually returns it but the CLI drops it on persist (a capture bug) versus the server genuinely not issuing one, since the fix differs. And the keychain-vs-file fallback question is worth resolving: if Credential Manager is available and the code still chooses file-backed storage, that points at a capability-detection issue that could also explain the key divergence. Do you have visibility into which path is taken on this Windows machine, or a log you could add to confirm?

Credential lifecycle observability is part of what I build at https://agentkey.us.

[benrrr56-wq]

4. The duplicated token-cache hashes for one server URL + scope is the interesting signal: 13 token files, one client-registration file, and two byte-identical expiresAt values written in the same second. That points at the cache key using something that is not the stable server identity, so one OAuth completion lands under two hashes. Separately, the absence of refreshToken for a PKCE public client means expiry is always a full browser consent, and an ~75-90 minute lifetime makes that constant. Edge: if the token file is keyed partially by a redirect or nonce that differs run to run, silent refresh can never find the prior grant. Question: is the token-cache key derived from client_id + token endpoint + requested scope (stable), and if refresh tokens are deliberately stripped for public clients, what is the recovery path besides re-consent? Founder of AgentKey here (https://agentkey.us), an auth+evidence layer for AI agents; token lifecycle attribution is exactly what we track.

[DaveHolden2025]

@benrrr56-wq — thanks, these are the right questions to chase. I pulled concrete data from the affected machine (Windows 11) to answer directly rather than speculate:

1. Storage path — confirmed file-based, not keychain. All 13 entries live under ~/.copilot/mcp-oauth-config/*.tokens.json. cmdkey /list shows no Credential Manager entry for this MCP server at all. Credential Manager is available and is used elsewhere by Copilot CLI on this same machine (there's a copilot-language-server/oauth-token-key generic credential for the CLI's own GitHub login) — so this isn't "Credential Manager unavailable," it's specifically that MCP-server OAuth tokens never land there. I can't tell from the client side whether that's by design (file-only for MCP tokens today) or a capability-detection gap — worth a maintainer confirming which.

2. Cache-key stability — this is the key finding. The client-registration file for this server has been a single file since it was first created (filesystem CreationTime = Aug 11), only ever updated in place — so that key derivation is stable. Over the same three-week window the token cache accumulated 13 different hashes for the identical server + scope — so the token-key derivation is demonstrably not stable, even though it's presumably meant to key off the same server identity as the registration.

Better still, I could directly verify one of the duplicate pairs (same expiresAt epoch): I hashed the accessToken string (SHA-256) from both files — identical. Same scope too. So it's not just two similarly-timed tokens, it's the exact same persisted payload duplicated under two different hashes. Filesystem timestamps show them written ~6ms apart: one was an in-place update to the pre-existing hash file, the other a brand-new file under a different hash, at essentially the same instant. That rules out "two independent OAuth completions racing" (each would mint its own distinct token from the authorization server) — this looks like a single resolved token getting persisted via two near-simultaneous save calls that each computed a different cache key for it (e.g., two parallel sessions/processes sharing one in-flight token resolution, each independently deriving its own key rather than agreeing on one).

3. Likely unstable ingredient. The registration file persists a concrete ephemeral loopback redirect URI (http://127.0.0.1:<port>/) — nothing in mcp-config.json configures this, so it's chosen automatically per flow. That's the most plausible unstable input if it (or something similarly per-attempt, like a state/nonce) is folded into the token cache key but not into the registration cache key.

4. refreshToken. Every one of the 13 files, oldest (Aug 11) through newest (Sep 1), uses the identical 3-field schema: accessToken, expiresAt, scope — never a refreshToken key, not even null. That consistency over three weeks and multiple token issuances suggests the persisted shape just doesn't carry one at all, but I can't confirm server-side behavior (whether one is ever issued and silently dropped) without a network capture of the token exchange — someone with visibility into that code would need to confirm.

Bonus finding: there's also an orphaned <hash>.verifier file (PKCE code_verifier, 43 chars — consistent with a standard 32-byte value) under the canonical hash, timestamped this morning, about 45 minutes before this comment, with no new token written since. Looks like an interactive re-auth got started but never finished/persisted — a smaller, probably-related cleanup issue.

For what it's worth: the most recent cached token (expiresAt ~05:19 UTC today) has already expired as of this comment, and with no refresh token the next call to this server will trigger a full interactive consent again — so this is actively reproducing right now, not just historically.

I've deliberately kept actual token values, the internal server hostname, client ID, and exact port out of this reply since they aren't needed to diagnose the bug — happy to share more (redacted) detail if it would help a maintainer dig in.