[BUG] Streamable HTTP MCP: in-flight tool call Promise orphaned forever on connection drop

Resolved 💬 3 comments Opened May 4, 2026 by glundgren93 Closed May 8, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When an HTTP SSE connection to a Streamable HTTP MCP server drops while a tool call is in-flight, the pending Promise is never resolved or rejected. The tool hangs indefinitely until the user manually cancels (Escape). The connection remains broken afterward — the user must manually reconnect via /mcp for subsequent calls to work.

Steps to Reproduce

  1. Configure a Streamable HTTP MCP server (e.g., hosted on AWS Bedrock AgentCore)
  2. Use it normally for 30+ minutes (long enough for a server-side session timeout or network blip)
  3. Trigger a tool call right as the HTTP connection drops (or force a drop by restarting the server)
  4. The tool call hangs indefinitely with "still running (30s elapsed)..." messages
  5. Only recovery: press Escape to cancel, then manually run /mcp to reconnect

Expected Behavior

When the HTTP SSE connection drops, all pending request Promises should be immediately rejected with an error (e.g., "connection lost"), and the client should automatically reconnect for subsequent calls.

Actual Behavior

09:50:02 — Tool 'workspace_load' dispatched
09:50:04 — HTTP connection dropped after 2820s uptime
09:50:04 — Connection error: Received a response for an unknown message ID (server's -32010 error for dead session)
09:50:32 — Tool 'workspace_load' still running (30s elapsed)
09:50:41 — user-cancel after 38s (only way to recover)

After cancel, the connection remains broken. User must manually /mcp reconnect (~9 min later in this case):

09:57:59 — User triggers /mcp reconnect (settings.local.json change detected)
09:59:45 — "HTTP transport closed/disconnected, attempting automatic reconnection"
09:59:48 — "HTTP reconnection successful after 3182ms (attempt 1)"
09:59:53 — workspace_load succeeds in 17s

Once reconnected, everything works normally (subsequent calls: 5s, 1s, 12s).

Root Cause

The MCP SDK's StreamableHTTPClientTransport detects the connection drop but doesn't:

  1. Reject Promises for requests that were in-flight on the old connection
  2. Automatically trigger reconnection after the drop

The timeoutMs: 60000 option only applies to connection setup, not to individual tool calls. There is no per-request timeout.

Proposed Fix

  1. When the HTTP connection drops (SSE stream closes), immediately reject all pending request Promises with a connection error
  2. Automatically trigger reconnection after a connection drop (don't wait for user to run /mcp)
  3. Optionally, expose a configurable per-tool-call timeout (e.g., MCP_TOOL_TIMEOUT) that races each callTool with a deadline

Related Issues

  • #43342 — Plugin MCP tools hang indefinitely with no timeout or error
  • #47076 — Make MCP tool call timeout configurable (MCP_TOOL_TIMEOUT)
  • #27142 — Streamable HTTP client does not re-initialize after session invalidation
  • #15758 — MCP tools silently disappear mid-session
  • #36308 — MCP servers should auto-reconnect when disconnected

Environment Info

  • Platform: darwin (macOS)
  • Version: 2.1.126
  • Transport: Streamable HTTP ("type": "http")
  • MCP server: Custom server on AWS Bedrock AgentCore Runtime

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗