HTTP MCP transport: hardcoded 5-attempt reconnect cap leaves transport permanently dead after upstream server restart (runtime, not startup)

Note: This is not the startup race fixed in 2.1.81 (#30464). This is runtime reconnection of an MCP transport that connected successfully and later loses contact when the HTTP MCP server restarts. After 5 attempts the client logs Max reconnection attempts (5) reached, giving up and the MCP server stays unavailable for the rest of the claude process — only claude restart recovers.

Environment

• Claude Code 2.1.123 on Linux (Bun runtime)
• Self-hosted HTTP MCP server, single replica behind nginx (TLS + bearer auth), Kubernetes-deployed
• Recreate deploy strategy (single-writer SQLite backend) → every restart is a brief outage

Outage profile we routinely see

• Routine pod restart: 30-90s (image pull + app boot + readiness probe)
• Eviction or unplanned restart: 1-2 minutes
• The 5-attempt cap with default backoff finishes inside the outage, marking the transport dead before the server is back

What we'd want

Either (a) a configurable maxReconnectAttempts and backoff (initial/multiplier/max-delay) per server in .mcp.json, or (b) infinite retry with capped exponential backoff for type: http servers. Even an /mcp reconnect slash-command would be a useful escape hatch.

References

Originally tried to comment on the existing reports but they're all closed as duplicates of #30464, which addressed a different (startup) race. Filing fresh per the auto-close bot's "If this is incorrect, please re-open this issue or create a new one" guidance.

Locked predecessors: #30464, #31198, #10129, #23081