HTTP MCP OAuth reconnect fails with "MCP endpoint not found at <origin>" right after successful token exchange

Summary

Connecting to a remote MCP server over the http transport with OAuth (WordPress + Novamira plugin) completes the OAuth authorization flow successfully via /mcp → Authenticate ("Got new credentials"), but the subsequent reconnect immediately fails with:

Got new credentials, but reconnecting to novamira-yoursite failed: MCP endpoint not found at https://yoursite.example. Check the URL in your MCP config.

Note the error reports only the bare origin (https://yoursite.example), not the full configured resource path (https://yoursite.example/wp-json/mcp/novamira-oauth). That truncation is suspicious — it suggests the client may be losing or mis-resolving the resource path somewhere after the OAuth handshake completes, rather than the server actually returning a 404.

Config (.claude.json, project-scoped)

"mcpServers": {
  "novamira-yoursite": {
    "type": "http",
    "url": "https://yoursite.example/wp-json/mcp/novamira-oauth"
  }
}

Also reproduced using the documented setup command:

claude mcp add novamira-yoursite --transport http https://yoursite.example/wp-json/mcp/novamira-oauth

What we've ruled out server-side

• Directly querying the endpoint (GET/POST, various User-Agents, with/without trailing slash) always returns a clean 401 with a correct header:

WWW-Authenticate: Bearer resource_metadata="https://yoursite.example/.well-known/oauth-protected-resource"
— no redirects, no Cloudflare challenge/403.

• /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource both return valid, self-consistent JSON metadata (200).
• The WordPress plugin (Novamira 1.10.1 — the latest, which specifically shipped a fix in this same version for "OAuth discovery documents requested with resource path appended/inserted" previously returning 404) reports its own built-in connection diagnostic as fully green, including:
• OAuth storage: OK
• OAuth discovery: OK
• OAuth client registration: OK — "a test registration succeeded"
• Hosting bot filter: OK
• Cloudflare sits in front of the zone. We added a WAF custom rule to skip Bot Fight Mode / rate-limiting for /wp-json/mcp/novamira* and /.well-known/oauth-*, with no change in behavior. Direct curl testing (from a residential IP) shows no Cloudflare challenge/403 on this endpoint at any point.
• Claude Code itself runs locally (not from a datacenter IP), so Cloudflare bot-management aimed at datacenter IPs doesn't plausibly explain a failure at the reconnect step specifically (it does affect unrelated tool calls made from Claude's own sandboxed tools to third-party sites, but not this local MCP client-to-origin connection).

Reproduction steps

1. claude mcp add novamira-yoursite --transport http https://yoursite.example/wp-json/mcp/novamira-oauth (or add manually to .claude.json)
2. /mcp → select the server → Authenticate → completes the browser OAuth flow without error
3. /mcp → reconnect → Got new credentials, but reconnecting to novamira-yoursite failed: MCP endpoint not found at https://yoursite.example. Check the URL in your MCP config.
4. Clearing auth (/mcp → clear authentication) and repeating is consistent; sometimes an immediate retry (no fresh OAuth) instead reports Failed to reconnect ...: MCP endpoint not found ... or requires authentication. Use the 'Authenticate' option.
5. /reload-plugins between attempts does not change the outcome.

Environment

• Claude Code: 2.1.220
• OS: macOS 26.5.2 (BuildVersion 25F84), Darwin 25.5.0
• MCP server: remote HTTP + OAuth (WordPress REST route via Novamira plugin 1.10.1, WordPress 7.0.2, PHP 8.3.30)

Ask

Given the error message truncates to the bare origin instead of the configured resource path, this looks like it could be a bug in how the OAuth-authenticated Streamable HTTP client resolves/retains the resource URL after token exchange, rather than a genuine "endpoint not found" from the server. We'd appreciate:

• Confirmation of whether this matches a known issue
• Guidance on any client-side debug flags/logs we could capture to tell whether this is a URL-handling bug vs. something in how the client parses the response to the actual MCP initialize call

Happy to provide additional diagnostics (HAR-style request/response capture, etc.) on request.

Possibly related open issues

This may be part of the same general bug family where a non-2xx or unexpected-shape response after/around auth gets misrouted into generic OAuth-error handling and surfaces a confusing, under-specified message instead of the real cause:

• #75976 — HTTP MCP session-404 not re-initialized, routed into OAuth error parsing
• #73537 — mid-session 401 wedges into OAuth fallback
• #70706 — [DOCS] MCP HTTP 404 error messages don't document the URL/MCP-config pointer (this is literally the message format we're hitting: "...Check the URL in your MCP config.")
• #80731 — OAuth login ignores RFC 9728 protected-resource-metadata discovery, targets resource origin for /authorize and /oauth2/token

Our case differs from #80731 in that the resource server and authorization server are the same host here, and the actual browser OAuth login step completes successfully ("Got new credentials") — the failure happens one step later, when the client tries to actually use the token against the MCP resource endpoint.