Server hangs forever at "Connecting..." when reconnecting with cached (still-valid) OAuth tokens

[hongwei1]

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.4.0 (reproduced with both npx @modelcontextprotocol/inspector and a global npm install -g install)

Node version

v26.5.0

Operating system (and browser, for the web client)

macOS 26.5.2, Chrome

Transport

Streamable HTTP

MCP server under inspection

Server: https://k8s-mcp2.openbankproject.com/mcp — a public, OAuth 2.1-protected FastMCP (Python) server (the Open Bank Project's MCP server).
Protocol era: modern
OAuth: yes — DCR + authorization code + PKCE (S256) against a separate OIDC provider (k8s-oidc.openbankproject.com).

This server is public and self-service: anyone can create a free test account at https://k8s-portal.openbankproject.com/register and use it to log in when the Inspector redirects to the sign-in page.

Steps to reproduce

1. Connect to the server above via a fresh authorization (DCR → OAuth redirect → login → token exchange). This part works correctly and reaches Connected.
2. Toggle the server off, then quit/restart the Inspector process (or just reload the page — the cached OAuth state in ~/.mcp-inspector/storage/oauth.json persists across both).
3. Toggle the server back on.

Expected behavior

Either: (a) silently reuse the still-valid cached access token and reach Connected without a new login prompt, or (b) if the cached token needs to be validated/refreshed, do so and fall back to a fresh OAuth redirect within a bounded time if that fails.

Actual behavior

The server gets stuck at Connecting... (yellow status dot) indefinitely — no timeout, no error message, no OAuth redirect, nothing actionable in the UI.

I checked the browser's Network tab during this: no request is sent to the target server or its OIDC provider at all. The only traffic is the usual local calls to the Inspector's own backend (/api/servers, /api/servers/events, /api/config, /api/storage/client). This makes sense once you notice the actual Streamable HTTP connection is established server-side, from the Inspector's local Node process — so whatever is hanging is happening inside that process, invisible to browser devtools. I could see (via lsof on the Inspector process) an established outbound HTTPS connection to the target server's IP that just sits there without resolving.

I confirmed the trigger precisely: deleting ~/.mcp-inspector/storage/oauth.json and restarting the Inspector immediately fixes it — the very next connection attempt goes straight to a fresh OAuth redirect and completes normally, every time. The file being deleted at the time of the hang contained non-expired cached tokens for this server (expires_in: 28800, issued ~3.5 hours earlier) plus the DCR-registered client credentials and full authorizationServerMetadata discovery cache. So this isn't an expired-token edge case — it reproduces with tokens that are still well within their validity window.

I did not find any UI affordance (in the server card, its Settings panel, or elsewhere) to clear cached auth state and force a fresh login — deleting the file by hand was the only way I found to recover. If there is one and I missed it, apologies — but it wasn't discoverable from the Servers tab.

Net effect: once a server has been successfully authorized once, the second connection attempt (after any restart or reload) has a good chance of permanently hanging, with no visible cause and no in-app recovery path.

Logs, errors, or screenshots

lsof on the Inspector process while stuck at Connecting...:

node    <pid> ... TCP 127.0.0.1:6274->127.0.0.1:<browser-port> (ESTABLISHED)   # browser <-> inspector, normal
node    <pid> ... TCP 192.168.x.x:<port>->3.68.148.37:443 (ESTABLISHED)        # inspector -> target server, hung

Cached auth file shape at the time (~/.mcp-inspector/storage/oauth.json, values redacted, structure intact):

{
  "servers": {
    "https://k8s-mcp2.openbankproject.com/mcp": {
      "discoveryState": { "authorizationServerUrl": "...", "resourceMetadataUrl": "...", "resourceMetadata": {...}, "authorizationServerMetadata": {...} },
      "byIssuer": {
        "https://k8s-oidc.openbankproject.com/obp-oidc": {
          "clientInformation": { "client_id": "...", "client_secret": "...", "token_endpoint_auth_method": "none", "grant_types": ["authorization_code", "refresh_token"], ... },
          "clientRegistrationKind": "dcr",
          "tokens": { "access_token": "...", "id_token": "...", "token_type": "Bearer", "expires_in": 28800, "refresh_token": "...", "issuer": "..." }
        }
      },
      "activeIssuer": "...",
      "codeVerifier": "...",
      "scope": "openid profile email"
    }
  },
  "idpSessions": {}
}

Fix that reliably unsticks it, every time:

rm -f ~/.mcp-inspector/storage/oauth.json
# restart the Inspector, then reconnect — goes straight to a fresh OAuth redirect and succeeds

Related: I also filed #2187 against the same server, for a different (later-stage) issue — tools/list timing out after reaching Connected. That one is unrelated to auth caching; flagging only because both surfaced from the same debugging session against the same FastMCP-based server.

Already prototyped a fix?

No — I don't have a fix, just the isolation above: the hang correlates specifically with the presence of ~/.mcp-inspector/storage/oauth.json for this server, not with token expiry, transport, or the server itself (a fresh, cache-less connection to the same server works every time).

[hongwei1]

Correction to my own report: there is a UI control for this, I just missed it — apologies for the noise.

Location: on the server card, click Settings → scroll down → expand OAuth Settings → red "Clear stored OAuth state" button at the bottom ("Removes stored tokens and client registration for this server. Disconnects if this server is currently connected.").

So the "no recovery path in the UI" part of my report is wrong — please disregard that specific claim. The rest of the report stands: the hang itself is still real and still reproduces with a still-valid cached token, and clicking that button (or deleting ~/.mcp-inspector/storage/oauth.json by hand) is the fix, it's just that a manual UI control for it already exists — I'd just missed where.

One thing worth considering, though: since the failure mode is a silent, indefinite hang with no error surfaced in the Connecting... state, a user hitting this has no clue that "clear stored OAuth state" is the fix, or that the button even exists, unless they already suspect stale auth and go looking for it. So the underlying bug (should degrade to a fresh OAuth redirect automatically, or surface an error/timeout pointing at this control) is unchanged — this correction only affects the "is there a manual escape hatch" question, not whether the hang itself needs fixing.

[cliffhall]

Triage: Priority = Medium

Scored 8/16 with the priority rubric in .claude/skills/issue-triage. Added to project board #28 with Status Incoming — filed and scored, but not yet approved for work. A maintainer decides whether it moves to Todo.

Axis	Score	Reasoning
Severity / impact	4/5	Reconnecting to an OAuth-protected server is a core workflow, and it hangs indefinitely with no timeout, no error and no redirect — the Inspector surfaces nothing at all, which is the worst shape a failure can take in a debugging tool. Recoverable, but only by discarding valid credentials.
Urgency / staleness	3/5	Reproduces on published 2.4.0 and is wanted this milestone; a workaround exists (Settings → OAuth Settings → Clear stored OAuth state, per your own follow-up) and nothing else is blocked on it.
Signal bonuses	+1	bug label. (No milestone — by rule, a pass-1 triage has none yet. No assignee, no reporter-set Fields → Priority, no high engagement.)
Total	8	Top of the Medium band (6–8).

Note. Your follow-up about the silent hang is the part I would keep front and centre when this is picked up: a bounded timeout with a surfaced error is arguably a separate, more general fix than whatever is stalling the cached-token path, and it would turn every future variant of this into something a user can act on rather than a spinner. Worth splitting into its own issue if the two fixes diverge.

Possibly related: #2187, also a hang/timeout against a modern Streamable HTTP OAuth server (same host). Worth checking whether they share a root cause before either is scheduled.

Thanks for the thorough report, and for the correction — the lsof observation that the stalled connection is outbound from the Node process narrows this considerably.

Scores are a starting point, not a verdict; a maintainer may override the band with a reason.