[Bug] OAuth discovery ignores URL path for subdirectory MCP servers

Bug Description
[Paste this in the /bug command prompt inside Claude Code] --- TITLE: MCP custom connector fails with start_error for WordPress installs in a subdirectory — OAuth discovery ignores URL path SUMMARY Adding a custom MCP connector in Claude.ai Web (Pro plan) with a URL in a subdirectory (e.g. https://example.com/protostar/wp-json/mcp/v1/sse) fails immediately at start-auth with step=start_error. The same server installed at the root (https://example.com/wp-json/mcp/v1/sse) works. Evidence suggests the backend probes .well-known/oauth-* on the root authority only, ignoring the path prefix, so it finds metadata belonging to a different install and aborts. ENVIRONMENT - Claude.ai Web, Pro plan, tested 2026-04-24 - Claude Code CLI 2.1.119 (same bug observed, see below) - Windows 11 Pro - MCP server: WordPress + AIWU plugin v1.4.15 (AI Copilot), OAuth 2.1 enabled ORG AND FLOW IDS (grep these in your logs) - Organization: d3e792f5-8816-4d8f-84a0-7a075f23c433 - Flow ID 1: ofid_5557e51696819332 - Flow ID 2: ofid_7f1b6e8601f35bd8 - Failing connector server ID: 5c7f780d-82bf-479a-802a-933e1eb29c28 - Working connector server ID: 89265253-940d-4236-902f-33c979542997 REPRO (Claude.ai Web) 1. Personalize → Connectors → Add custom connector 2. URL: https://autonomiesolaire.ca/protostar/wp-json/mcp/v1/sse (subdirectory install) 3. Click Connect 4. Backend returns 307 to /settings/connectors?step=start_error&flow_id=ofid_... in < 1s 5. UI shows "Couldn't reach the MCP server. ... share this reference with support: ofid_..." EXPECTED With the identical plugin installed at the root (https://autonomiesolaire.ca/wp-json/mcp/v1/sse), the connector works: start-auth returns 307 to the plugin's /oauth/authorize endpoint and the consent screen renders. Only variable that changed: the /protostar/ path prefix. EVIDENCE SERVER IS HEALTHY Direct cURL with Bearer header returns a valid SSE stream: event: endpoint data: https://.../protostar/wp-json/mcp/v1/messages?session_id=...&token=[REDACTED] event: heartbeat data: {"status":"alive"} The subdirectory install does NOT publish .well-known/oauth-protected-resource at /protostar/.well-known/... (404), but the root install does at /.well-known/... (200). WordPress rewrite rules cannot intercept .well-known/ below a subpath, so it's impossible for the subdirectory install to publish metadata at the subpath. Anthropic's discovery probes against the root find metadata for the other install → mismatch → start_error. SAME ROOT CAUSE IN CLAUDE CODE CLI Running claude mcp add --transport sse --header "Authorization: Bearer [REDACTED_TOKEN]" wp-staging <subdir-url> in CLI 2.1.119 also fails. MCP logs show the CLI ignoring the configured Bearer header and attempting an OAuth flow instead: "No token data found" (×3) "Connection timeout triggered after 30034ms" Even though cURL with the same Bearer header succeeds on the same endpoint. So the CLI has a related but distinct bug where headers.Authorization from .claude.json is not used for SSE transport when OAuth discovery fails. REQUEST Please fix OAuth discovery to honor the full URL path of MCP servers, or allow a per-connector override for the discovery URL. For Claude Code CLI specifically, please make headers.Authorization take precedence over OAuth discovery when the header is present in config. Full HAR files (~23 MB staging + ~120 KB live) and MCP CLI logs available on request.

Environment Info

• Platform: win32
• Terminal: pycharm
• Version: 2.1.119
• Feedback ID: f85076b4-7a6f-431f-b055-b2d7ab7f12d9

Errors

[]