claude-code - 💡(How to fix) Fix [Bug] OAuth discovery ignores URL path for subdirectory MCP servers [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52954Fetched 2026-04-25 06:16:17
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
0
Timeline (top)
labeled ×5commented ×2

Root Cause

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.

Code Example

[]
RAW_BUFFERClick to expand / collapse

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

[]

extent analysis

TL;DR

The MCP custom connector fails due to OAuth discovery ignoring the URL path, causing a mismatch in metadata, and a fix is needed to honor the full URL path or allow a per-connector override.

Guidance

  • The issue is likely caused by the backend probing .well-known/oauth-* on the root authority only, ignoring the path prefix, which leads to finding metadata belonging to a different install and aborting.
  • To verify, check the HAR files and MCP CLI logs for evidence of the OAuth discovery failure.
  • A potential workaround is to configure the MCP server to publish .well-known/oauth-protected-resource at the subpath, although this may not be possible due to WordPress rewrite rules.
  • The Claude Code CLI has a related bug where headers.Authorization is not used for SSE transport when OAuth discovery fails, which needs to be fixed.

Example

No code snippet is provided as the issue is more related to configuration and OAuth discovery.

Notes

The issue is specific to MCP custom connectors with URLs in subdirectories, and the fix should take into account the full URL path of MCP servers.

Recommendation

Apply a workaround by configuring the MCP server to publish .well-known/oauth-protected-resource at the root, if possible, or wait for a fix that honors the full URL path or allows a per-connector override.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] OAuth discovery ignores URL path for subdirectory MCP servers [2 comments, 2 participants]