[BUG] v2.1.205 regression: HTTP MCP session-404 not re-initialized — routed into OAuth error parsing ("Invalid OAuth error response")

Summary

Regression on v2.1.205: when an HTTP (Streamable) MCP server loses its session (process restart) and correctly answers the next request with HTTP 404, Claude Code does not start a new session as required by the MCP spec. Instead the 404 is routed into OAuth error parsing and the tool call fails with a confusing error. The connection stays wedged until a manual /mcp → reconnect.

This is the same failure class previously reported and closed in #9608, #50450, #60949 and #62008 (itself a regression report against the fix claimed in v2.1.41). It reproduces again on 2.1.205, now surfacing through the OAuth error path — related to the open #73537, which describes the same OAuth-fallback wedging for the mid-session 401 trigger; this report is the 404 session-loss trigger.

Environment

• Claude Code 2.1.205, reproduced on Windows 11 and macOS
• HTTP (Streamable) MCP server, custom bearer auth via static headers + headersHelper (no OAuth; server exposes no OAuth discovery endpoints)
• Server configured via enterprise managed-mcp.json:

"mcp-pmp": {
  "url": "https://<internal-host>/mcp",
  "type": "http",
  "headers": { "CLIENT_ID": "claude-code" },
  "headersHelper": "~/.config/digilera/mcp_jwt_header.cmd"
}

Steps to reproduce

1. Start a Claude Code session; the HTTP MCP server connects fine (claude mcp list → Connected; tool calls succeed).
2. Restart the MCP server process (its in-memory session store is lost).
3. Invoke any tool on that server.

Actual behavior

The server answers the stale-session POST with 404 and a plain-text body (Not Found) — per MCP Streamable HTTP spec for an unknown Mcp-Session-Id. Claude Code does not re-initialize. The tool call fails with:

HTTP 404: Invalid OAuth error response: SyntaxError: JSON Parse error:
Unexpected identifier "Not". Raw body: Not Found

Manual /mcp → reconnect resolves it (new initialize succeeds; note the bearer token was valid the whole time — this is not an auth failure).

Expected behavior

Per MCP spec (Streamable HTTP transport, Session Management): when a request carrying Mcp-Session-Id receives HTTP 404, the client MUST start a new session with a new InitializeRequest. Expected: transparent re-initialize (re-running headersHelper for fresh headers) + retry of the tool call, with no user-visible error.

Secondary issue

The 404 is routed into OAuth error parsing ("Invalid OAuth error response") although the server is not OAuth-based (auth is custom-header via headersHelper; no discovery endpoints exist). Non-OAuth HTTP MCP servers shouldn't enter the OAuth error/fallback path at all — same family as #73537 and #56357.

References

• #9608 — original report (closed)
• #50450 — spec-violation report (closed)
• #60949 — restart/404 not handled (closed)
• #62008 — regression of the v2.1.41 fix (closed)
• #62198 — 404 misinterpretation regression in v2.1.147 (closed)
• #73537 — open sibling: 401 trigger wedges into OAuth fallback
• MCP spec: Streamable HTTP transport — Session Management (2025-03-26 revision)