refactor(ui): route MCP session tokens through the shared storage helper

[yuneng-berri]

TLDR

Problem this solves:

• MCP session tokens bypassed the dashboard's shared storage helper
• The stored payload carried a refresh token nothing ever read
• Storage format was inconsistent with every other OAuth path

How it solves it:

• setToken / getToken now go through setSecureItem / getSecureItem
• Dropped refresh_token from the store and its four callers
• Added regression tests that decode storage before asserting

Relevant issues

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

mcpTokenStore is browser-side state with no proxy endpoint behind it, so the proof is the storage the dashboard actually writes, read out of the running UI

1. Start the proxy and the dashboard dev server, then open http://localhost:3000/ui/?page=mcp-servers
2. Create or edit an MCP server whose auth type is true_passthrough or oauth_delegate, and complete the upstream Authorize
3. Open DevTools, Application, Session Storage, and select the dashboard origin
4. Find the mcp-session-token:<user_id>:<server_id> entry
5. Before this change the value reads as JSON with access_token and refresh_token in plain view; after it reads as an opaque encoded string carrying only access_token, expires_at, and token_type
6. Open the server's Tools tab and confirm the tool list still loads, which proves the round trip through getToken still resolves the upstream token

Type

🧹 Refactoring

Changes

mcpTokenStore was the only place in the dashboard that wrote an OAuth payload straight to window.sessionStorage; every other OAuth path (useMcpOAuthFlow, useToolsOAuthFlow, the callback page, the edit-screen UI state) already goes through the shared secureStorage helper. This lines the store up with the rest of them, so there is one storage format across the OAuth surface instead of two

The stored payload also carried refresh_token, and nothing ever read it back. The three call sites that read the store all take access_token only, and there is no direct read of the mcp-session-token: keys anywhere else, so the field was write-only from the day it was added. The client-forwarded modes (true_passthrough and oauth_delegate) deliberately keep the upstream token out of LiteLLM and refresh by re-authorizing, so nothing needs it; authorization_code is unaffected because it persists through storeMCPOAuthUserCredential on the backend, which keeps its own refresh token. Dropping the field removes it from the store and from the four callers that were populating it

Existing sessions holding a pre-change entry decode to null and are treated as absent, which surfaces the normal Authorize prompt. These entries are session-scoped and expire in an hour, so the effect is limited to re-authorizing once

Two regression tests cover the store. Both decode the stored value before asserting, so neither can pass just because the payload is no longer plain text; verified red against the previous implementation and green against this one

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

Greptile Summary

Routes browser-held MCP session tokens through the dashboard's shared storage helper and removes unused refresh tokens from that storage path

• Replaces direct session-storage serialization with setSecureItem and getSecureItem
• Removes refresh tokens from browser-held token payloads across MCP creation, editing, and tool authorization flows
• Adds regression coverage for encoded storage and refresh-token exclusion

Confidence Score: 5/5

The PR appears safe to merge

No blocking failure remains; the prior test concern is invalid because the ASCII JSON payload is fully exposed by base64 decoding, so restoring refresh-token persistence would fail the regression assertion

Important Files Changed

Filename	Overview
ui/litellm-dashboard/src/utils/mcpTokenStore.ts	Uses the shared secure-storage encoding path and narrows the stored MCP token shape to required access-token metadata
ui/litellm-dashboard/src/utils/mcpTokenStore.test.ts	Adds effective regression checks that inspect encoded session storage and detect any restored refresh-token persistence
ui/litellm-dashboard/src/hooks/useToolsOAuthFlow.tsx	Stops forwarding refresh tokens into the browser-side MCP token store
ui/litellm-dashboard/src/app/(dashboard)/mcp-servers/_components/CreateMCPServer.tsx	Removes refresh tokens from browser-held MCP token payloads while preserving backend credential persistence for authorization-code mode
ui/litellm-dashboard/src/app/(dashboard)/mcp-servers/_components/mcp_server_edit.tsx	Removes refresh tokens from both staged and committed browser-held MCP token payloads

_{Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/lit..." | Re-trigger Greptile}

[yuneng-berri]

@greptileai