mcp: re-mint expired managed proxy tokens on demand instead of failing or misrouting to OAuth - #15538
Conversation
…g or misrouting to OAuth
This was referenced Aug 25, 2026
Contributor
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Aug 25, 2026
Draft
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problem
Managed (backend-proxied) MCP servers authenticate with a short-lived proxy session token minted once per run via
createManagedMcpClientConfig. Six of the mutation's eight response fields were dead code; nothing retained the manageduid. When the token expired (external sessions: 3h), every tool call failed for the rest of the run — the explicit v1 deferral inspecs/managed-mcp-cli-resolution/TECH.md. Worse, an expired token at spawn time routed into the interactive OAuth flow with a misleading "Please authenticate this server in the Warp desktop app" message.Changes
uid(ResolvedMcpSpecs.managed_uids).spawn_managed_ephemeral_servercarrying anInstallationRefresher: a closure that re-mints the client config (bounded retry — it sits on the tool-call latency path), re-parses it, and rebuilds the installation preserving the installation UUID (random for local runs, keys all manager state) and template UUID (keys the log file), then re-applies secrets.reconnect_serverinvokes the refresher before respawning a managed server, so the end-to-end reactive path is: mid-run 401proxy_token_expired→ classified recoverable (prev PR) → retry via reconnect → re-mint → respawn with the fresh header → tool call succeeds, nothing surfaced to the user. Overlap-safe: proxy sessions are stateless JWTs server-side; the old token stays valid until its expiry.WWW-Authenticate, and a proxy re-mint reason returns a typedAuthRequired { reason: Some(..) }instead of entering the OAuth flow (no credential deletion either, per the guard in the classification PR).Flag-gated by
McpSelfHeal. Not covered (by design): third-party harnesses receive rendered JSON config and own their MCP connections; and an initial spawn hittingAuthRequireddoes not auto-re-mint — resolution happens seconds before spawn, so a token expired at that point indicates clock skew rather than age.Tests
MockManagedMcpClienttests: refresher preserves identities and swaps only the Authorization value (asserted via rendered config), errors cleanly when the server disappears from the re-minted config, resolution records uids for both UUID and well-known specs; axum test asserts the preflight returnsAuthRequired{Some(ProxyTokenExpired)}instead of the OAuth path.