Plain HTTP 403 without WWW-Authenticate starts OAuth discovery in the Inspector web client #2515

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.7.0 (also tested against 2.8.0 source code)

Node version

v26.5.0

Operating system (and browser, for the web client)

macOS 27.0, Chrome 153.0.8010.54

Transport

Streamable HTTP

MCP server under inspection

A disposable local Soklet MCP server using Streamable HTTP and the modern 2026-07-28 protocol. Soklet is a Java MCP server under active development. Inspector connects to http://127.0.0.1:/mcp with a valid static bearer credential. The server permits Apps catalog reads and tool calls, but intentionally denies subscriptions/listen with HTTP 403 and no WWW-Authenticate header. It has no OAuth authorization server. The port and credential are temporary.

Steps to reproduce

1. Connect Inspector’s web client to the server above using Streamable HTTP, the modern protocol, and the valid bearer credential.
2. Open the Apps catalog and select the app. Its catalog data renders, and a refresh succeeds.
3. Inspector automatically requests subscriptions/listen. The server returns HTTP 403 without WWW-Authenticate.
4. Observe Inspector attempt OAuth discovery and client registration despite the absence of an OAuth challenge.

Expected behavior

Treat this response as an ordinary denial of that operation. Preserve the 403 response for the MCP caller and do not start OAuth discovery. A genuine 401 challenge or a 403 with WWW-Authenticate: Bearer error="insufficient_scope" should still follow Inspector’s existing authorization flow.

Actual behavior

Inspector treats the plain 403 as an OAuth challenge and attempts protected-resource metadata discovery, authorization-server discovery, and client registration. The app itself rendered and refreshed, but this unsolicited OAuth recovery prevents the full Apps host check from passing.

Logs, errors, or screenshots

Sanitized observation from the Inspector 2.7.0 web run: a valid credential was accepted; subscriptions/listen received HTTP 403 with no WWW-Authenticate; Inspector then requested OAuth well-known endpoints and /register. No browser screenshot was captured. The credential and temporary port are omitted.
A focused check of Inspector 2.8.0 source also shows parseAuthChallengeFromResponse() classifying a 403 response without WWW-Authenticate as reason: "unauthorized".

Already prototyped a fix?

Yes. We tested a local change against clean Inspector 2.8.0 source so a 403 without WWW-Authenticate is left as a normal response. Three focused regression tests failed before the change and passed after it; the relevant test suite passed 65/65, as did the TypeScript build and targeted formatting and lint checks. This is an unpublished local prototype. The exact user message authorizing the approach was “Let's go with your recommended approach then.” No before/after UI screenshots were captured; the before/after evidence is the test results.

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).