claude-code - 💡(How to fix) Fix MCP HTTP transport: SDK attempts OAuth discovery even when Bearer token headers are configured [1 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#56357Fetched 2026-05-06 06:30:17
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
0
Author
Timeline (top)
commented ×1

When an MCP server is configured with type: http and explicit headers: { Authorization: "Bearer ..." }, the SDK still attempts OAuth discovery by probing /.well-known/oauth-authorization-server at the server root. If the server returns anything other than a definitive 404 (e.g., empty JSON {}), the SDK caches an authServer discovery state and repeatedly attempts OAuth flow on reconnect, ignoring the configured Bearer token.

Error Message

{"debug":"Saving discovery state (authServer: http://hindclaw:8888/)","timestamp":"..."} {"debug":"No client info found","timestamp":"..."} {"debug":"SDK auth error: HTTP 404: Invalid OAuth error response: ZodError: [...]"}

Root Cause

When an MCP server is configured with type: http and explicit headers: { Authorization: "Bearer ..." }, the SDK still attempts OAuth discovery by probing /.well-known/oauth-authorization-server at the server root. If the server returns anything other than a definitive 404 (e.g., empty JSON {}), the SDK caches an authServer discovery state and repeatedly attempts OAuth flow on reconnect, ignoring the configured Bearer token.

Fix Action

Workaround

Server-side: return explicit 404 for /.well-known/oauth-authorization-server Client-side: remove and re-add the MCP server config

Code Example

{
  "mcpServers": {
    "my-server": {
      "type": "http",
      "url": "http://example:8888/mcp/endpoint",
      "headers": {
        "Authorization": "Bearer my-api-key"
      }
    }
  }
}

---

{"debug":"Saving discovery state (authServer: http://hindclaw:8888/)","timestamp":"..."}
{"debug":"No client info found","timestamp":"..."}
{"debug":"SDK auth error: HTTP 404: Invalid OAuth error response: ZodError: [...]"}
RAW_BUFFERClick to expand / collapse

Description

When an MCP server is configured with type: http and explicit headers: { Authorization: "Bearer ..." }, the SDK still attempts OAuth discovery by probing /.well-known/oauth-authorization-server at the server root. If the server returns anything other than a definitive 404 (e.g., empty JSON {}), the SDK caches an authServer discovery state and repeatedly attempts OAuth flow on reconnect, ignoring the configured Bearer token.

Reproduction

  1. Configure an HTTP MCP server with Bearer token auth:
{
  "mcpServers": {
    "my-server": {
      "type": "http",
      "url": "http://example:8888/mcp/endpoint",
      "headers": {
        "Authorization": "Bearer my-api-key"
      }
    }
  }
}
  1. The server does NOT support OAuth but returns {} (empty JSON) for unknown paths instead of 404.

  2. On connect, SDK probes http://example:8888/.well-known/oauth-authorization-server, gets {}, caches authServer: http://example:8888/, then attempts OAuth token exchange which fails with 404.

  3. Result: server shows "needs authentication" despite valid Bearer token in config.

  4. Workaround: claude mcp remove + claude mcp add clears the cached discovery state temporarily, but it recurs on next session or reconnect.

Expected Behavior

When headers.Authorization is already configured with a Bearer token, the SDK should:

  • Skip OAuth discovery entirely, OR
  • Only attempt OAuth if the initial request with the configured headers returns 401

Observed Behavior

  • SDK probes for OAuth metadata regardless of existing auth headers
  • If the probe returns anything parseable (even empty {}), it caches discovery state
  • Subsequent connection attempts use OAuth flow instead of the configured headers
  • The hindsight-user server with identical config sometimes works while hindsight-shared fails (timing/race condition in discovery)

Environment

  • Claude Code CLI v1.0.x
  • macOS
  • MCP server: Hindsight API (Streamable HTTP transport)

MCP Log Evidence

{"debug":"Saving discovery state (authServer: http://hindclaw:8888/)","timestamp":"..."}
{"debug":"No client info found","timestamp":"..."}
{"debug":"SDK auth error: HTTP 404: Invalid OAuth error response: ZodError: [...]"}

Workaround

Server-side: return explicit 404 for /.well-known/oauth-authorization-server Client-side: remove and re-add the MCP server config

extent analysis

TL;DR

The SDK can be fixed by modifying it to skip OAuth discovery when a Bearer token is already configured in the headers.

Guidance

  • Verify that the MCP server returns a definitive 404 for /.well-known/oauth-authorization-server to prevent the SDK from caching an authServer discovery state.
  • Check the SDK configuration to ensure that the headers.Authorization field is correctly set with the Bearer token.
  • Consider implementing a server-side workaround by returning an explicit 404 for /.well-known/oauth-authorization-server to prevent the SDK from attempting OAuth discovery.
  • Review the SDK code to determine why it is not skipping OAuth discovery when a Bearer token is already configured in the headers.

Example

No code snippet is provided as the issue does not require a code change, but rather a configuration or server-side modification.

Notes

The issue may be related to a timing or race condition in the discovery process, as evidenced by the fact that the hindsight-user server sometimes works while hindsight-shared fails.

Recommendation

Apply a server-side workaround by returning an explicit 404 for /.well-known/oauth-authorization-server to prevent the SDK from attempting OAuth discovery, as this is a more reliable and efficient solution than modifying the SDK or client-side configuration.

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 MCP HTTP transport: SDK attempts OAuth discovery even when Bearer token headers are configured [1 comments, 2 participants]