Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix HTTP MCP Servers Don't Auto-Reconnect After Transient Startup Failures

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…

Root Cause

Root Cause: Startup race condition when Claude Code starts before the MCP server host application.

Code Example

curl -s -o /dev/null -w "%{http_code}" https://server-base-url/mcp/calendar
# Returns: 200 (repeated for all 7 servers: mail, calendar, jira, microsoft-teams, sharepoint, github, confluence)
RAW_BUFFERClick to expand / collapse

Bug Report: HTTP MCP Servers Don't Auto-Reconnect After Transient Startup Failures

Observed Behavior

When Claude Code starts before the MCP server host application, it attempts connection to unavailable servers and permanently marks them as "failed" without retrying after servers become available. Manual reconnection via /mcp menu is required, despite servers being healthy and responsive.

Why This Is a Problem

Manual reconnection is tedious and disruptive:

  • Each server requires individual selection and reconnection
  • Total time: ~30-60 seconds to manually reconnect seven servers, 90m to troubleshoot and diagnose
  • No visibility into why connections are marked as failed (no connection failure logs)

Desired Outcome

HTTP MCP servers should auto-reconnect when they become available after transient startup failures. Users should not need to manually reconnect to healthy servers.

Reproduction

Root Cause: Startup race condition when Claude Code starts before the MCP server host application.

Timeline:

  • 09:18:26 PT - Laptop woke from sleep (full wake from deep idle)
  • ~09:24 PT - Claude Code session started
  • 09:29:31 PT - MCP server host application started (~5 minute delay)
  • ~09:32 PT - User discovers all MCP servers showing as "failed" in /mcp menu

What happened:

  1. Claude Code session initialized during laptop wake sequence
  2. MCP server host application had not started yet (5-6 minute startup delay)
  3. Claude Code attempted to connect to 7 HTTP MCP servers
  4. Connection failed (servers not listening yet)
  5. Claude Code marked all servers as "failed"
  6. MCP server host started, servers became available
  7. Claude Code never retried - servers remained "failed" despite being healthy

Evidence servers were healthy: Direct HTTP connectivity test during "failed" state showed all 7 servers responding:

curl -s -o /dev/null -w "%{http_code}" https://server-base-url/mcp/calendar
# Returns: 200 (repeated for all 7 servers: mail, calendar, jira, microsoft-teams, sharepoint, github, confluence)

Symptoms observed:

  • ToolSearch returns "No matching deferred tools found"
  • /mcp menu shows servers as "failed" or "disconnected"
  • Manual reconnection via /mcp menu succeeds immediately, all tools become available

Environment

  • OS: macOS 25.4.0 (Darwin)
  • Claude Code: 2.1.118
  • MCP Server Configuration: 7 HTTP-based servers hosted at same base URL with different path suffixes
  • MCP Transport: HTTP (not stdio)
  • Servers affected: mail, calendar, jira, microsoft-teams, sharepoint, github, confluence

Related Issues

#43177 - "MCP stdio servers never auto-reconnect after disconnect"

  • Documents that stdio servers are explicitly excluded from auto-reconnect logic
  • Comments state HTTP/SSE/WebSocket transports have exponential backoff reconnection (5 attempts, 1s-16s)
  • This issue shows HTTP servers also fail to auto-reconnect in startup race conditions

#55970 - "MCP HTTP-Streamable Server: Init-Handshake fails on reconnect"

  • Different symptom: stale session ID after server restart vs. servers never initialized at startup

Additional Observations

  • Debug logs (~/.claude/debug/latest) contain only message processing entries
  • No log entries for MCP connection attempts, failures, or retry logic
  • Suggests MCP connection management happens outside logged code paths or at different log level

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…
#network issue#logging issue#authentication issue#prompt issue#agent setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING