[BUG] HTTP OAuth MCP servers silently fail in Claude Code inside Claude Desktop — no error, no guidance

[HoldenCaulfieldRye]

Environment

• Claude Code version: 2.1.87
• Running inside: Claude Desktop (com.anthropic.claudefordesktop)
• Operating System: macOS 15 (Darwin 25.2.0)

Bug Description

When adding an HTTP MCP server that requires OAuth but doesn't support Dynamic Client Registration (DCR), Claude Code silently fails with no user-facing error. The server appears in config but never loads tools. This is especially confusing inside Claude Desktop where there are no debug logs visible.

The user experience is a multi-hour loop:

1. Run claude mcp add --transport http hubspot https://mcp.hubspot.com/anthropic
2. Config is written to ~/.claude.json ✓
3. Restart session — no hubspot tools appear, no error shown
4. User assumes config is wrong, tries again, creates duplicate entries at different scopes
5. Repeat

Steps to Reproduce

1. Open Claude Code inside Claude Desktop, cwd ~/git
2. In a separate terminal: claude mcp add hubspot --transport http https://mcp.hubspot.com/anthropic
3. Restart Claude Code session
4. No mcp__hubspot__* tools load. No error message. The mcp__hubspot__authenticate tool may appear but calling it returns: "SDK auth failed: Incompatible auth server: does not support dynamic client registration"

Root Causes Found (after hours of debugging)

1. Silent OAuth failure: The server returns 401 with OAuth metadata, Claude Code attempts DCR, it fails (no registration_endpoint), and the failure is swallowed. No message is shown to the user.

2. Scope shadowing: claude mcp add defaults to local scope, writing to ~/.claude.json under projects["/Users/username"]. If the user later manually adds a working config at user scope (top-level mcpServers), the broken local-scoped entry takes precedence due to the scope hierarchy (local > project > user). This is invisible and undocumented behavior.

3. Project-level .mcp.json override: If any session writes a .mcp.json to the working directory with the broken HTTP entry, it overrides the working user-level config in subsequent sessions.

Expected Behavior

1. Show an error when OAuth/DCR fails: "This server requires OAuth but doesn't support Dynamic Client Registration. Use a local MCP server with an API key instead, or configure OAuth client credentials manually."
2. Warn about scope shadowing when a server name exists at multiple scopes
3. Don't silently swallow connection failures — surface them in /mcp status or session startup

Workaround

Use the local npm package (@hubspot/mcp-server) with a Private App access token instead of the remote HTTP OAuth endpoint. Configure at user scope in ~/.claude.json:

"hubspot": {
  "command": "/opt/homebrew/bin/npx",
  "args": ["-y", "@hubspot/mcp-server"],
  "env": {
    "PRIVATE_APP_ACCESS_TOKEN": "pat-xxx"
  }
}

Related Issues

• [BUG] Claude Code does not work with MCP servers that does not implement Dynamic Client Registration #3273 — Claude Code doesn't work with MCP servers without DCR (CLI-focused, different angle)
• Support pre-configured OAuth client credentials without requiring Dynamic Client Registration #26675 — Support pre-configured OAuth client credentials without DCR
• macOS TCC permission prompt ("node would like to access data from other apps") on every launch and first message #36832 — macOS TCC permission popup looping (separate but co-occurs)

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Code does not work with MCP servers that does not implement Dynamic Client Registration #3273
2. [BUG] Official Greptile Plugin won't Authenticate: Error: SDK auth failed: Incompatible auth server: does not support dynamic client registration #45518
3. [BUG] Slack plugin fails to authenticate - "does not support dynamic client registration" #18009

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[HoldenCaulfieldRye]

Additional concern: Claude Code self-reinforces the bad path

After resolving this issue with the local npm workaround, we discovered a secondary problem: Claude Code itself repeatedly suggests the broken approach in new sessions, creating a loop.

The loop

1. User asks Claude Code to set up HubSpot MCP
2. Claude suggests claude mcp add --transport http hubspot https://mcp.hubspot.com/anthropic or offers to write a project-level .mcp.json — both broken paths
3. User restarts, nothing works, opens new session
4. New session's Claude suggests the same thing again (no memory of prior failure)
5. Even when the user has a memory file explicitly documenting "NEVER create ~/git/.mcp.json" and "remote HTTP OAuth MCPs silently fail," Claude still offered to create a project-level .mcp.json as a fix option

Why this matters

The workaround (local npm + API key) is non-obvious and requires domain knowledge the model doesn't have. Without it, users bounce between sessions for hours trying the same two broken approaches (HTTP OAuth, project-level config files) because that's what Claude confidently suggests each time.

Suggested mitigations

1. Surface the error at session startup: if an MCP server is configured but 0 tools loaded, show a warning: "Server hubspot is configured but no tools were registered. Run /mcp to debug."
2. Don't suggest claude mcp add --transport http for servers that are known to lack DCR support — or at minimum, warn that OAuth may not work and suggest checking for a local npm alternative first.
3. When Claude reads a memory/feedback file that says "NEVER do X", it should genuinely never offer X as an option — not even as choice 2 of 3.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.