Bundled HTTP MCP client times out against hosted SSE server even when endpoint responds in <1s

Summary

After upgrading from [email protected] → 2026.4.22, all HTTP-transport MCP servers pointing at https://mcp.agentmail.to/mcp fail to start at gateway boot with a 15–30s SSE/stream timeout. Direct curl to the same URL with the same auth header returns HTTP 200 with a valid initialize response in ~450ms, so the endpoint itself is healthy. The Claude Code MCP client (using its own stack, not OpenClaw's bundled one) connects to the same server fine. The bug appears isolated to OpenClaw's bundled HTTP/2 SSE transport in bundle-mcp subsystem.

Environment

Bug reproduces on both hosts, different node versions → rules out node-version-specific issue.

Reproduction

1. Register an HTTP MCP pointing at https://mcp.agentmail.to/mcp:

   openclaw mcp set agentmail-test '{"type":"http","url":"https://mcp.agentmail.to/mcp","headers":{"X-API-Key":"am_us_..."}}'

2. Restart gateway:

   launchctl kickstart -k gui/$UID/ai.openclaw.gateway

3. Watch gateway.log — MCP server fails to start with SSE / stream timeout.

Actual vs expected

Expected: MCP server initializes, tools list becomes available to agents.

Actual: Failure at startup in bundle-mcp subsystem. Two observed error variants:

[bundle-mcp] failed to start server "agentmail" (https://mcp.agentmail.to/mcp):
  Error: SSE error: TypeError: terminated: HTTP/2: "stream timeout after 15000"

[bundle-mcp] failed to start server "agentmail-dotstudiopro" (https://mcp.agentmail.to/mcp):
  Error: MCP server connection timed out after 30000ms

Downstream impact: each failed MCP adds 15–30s to gateway startup while the handshake blocks. Agents (Sam, Julian, Atlas) observably "slow to respond" immediately after any gateway restart. Once per-MCP timeout elapses, the gateway comes up cleanly but the tools from the failed server are never exposed.

Proof the endpoint is healthy (same URL, same key, different client)

From Mac Mini 1, same terminal context the gateway runs in:

$ curl -s -o /tmp/am.json -w "HTTP %{http_code} in %{time_total}s\n" --max-time 20 \
    -H "X-API-Key: am_us_..." \
    -H "Accept: application/json, text/event-stream" \
    -H "Content-Type: application/json" \
    -X POST https://mcp.agentmail.to/mcp \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"d","version":"0"}}}'

HTTP 200 in 0.448319s
event: message
data: {"result":{"protocolVersion":"2025-03-26","capabilities":{"tools":{"listChanged":true}},"serverInfo":{"name":"AgentMail","version":"1.0.0"}},"jsonrpc":"2.0","id":1}

Same URL, same auth, consistent ~450ms response.

Additionally: the same https://mcp.agentmail.to/mcp server registered in Claude Code (via npx add-mcp -a claude-code --transport http https://mcp.agentmail.to/mcp) connects without issue. So the bug is specific to OpenClaw's HTTP/2 SSE transport implementation, not the server.

Diagnostic signals

• Log source: /Users/joepascual/.openclaw/logs/gateway.log (Mac Studio) and /tmp/openclaw/openclaw-2026-04-23.log (mini1)
• Subsystem: bundle-mcp
• Call site reported in log: dist/subsystem-CJBoMDt5.js:324
• Node runtime version in log: runtimeVersion: "22.16.0" (Studio) / "24.14.0" (mini1)
• config validate passes — config shape is fine.
• Reproduction not dependent on any specific key/scope — both a personal org key and a new-org key fail identically.

Hypothesis

Likely a regression in one of the updated dependencies between 2026.4.12 and 2026.4.22. The npm install during upgrade reported changes to 434 packages and removed 462 — large enough that this could be a bundled undici or @modelcontextprotocol/sdk behavioral change against servers that negotiate HTTP/2.

Two plausible areas:

1. undici HTTP/2 handling — SSE-over-HTTP/2 keepalive semantics may have shifted.
2. @modelcontextprotocol/sdk — client transport timeout logic or headers may be incompatible with SSE servers that don't send keepalive frames within the default window.

The fact that the error surfaces as both "stream timeout after 15000" (HTTP/2 stream-level) and "MCP server connection timed out after 30000ms" (application-level SDK timeout) suggests the stream dies mid-handshake after initial bytes flow.

Workaround

openclaw mcp unset <name> + launchctl kickstart -k the gateway. Tools from the affected server are unavailable; all other functionality unaffected.

Impact

Any user attempting to use a hosted HTTP/SSE MCP on [email protected] has this tax at every gateway restart. In our setup the compounding effect (two MCPs × two hosts × multiple restarts over an afternoon during upgrade) made every agent on mini1 perceptibly slow for ~20 minutes.

Ask

1. Is there a known fix queued in main or a compatible @modelcontextprotocol/sdk / undici pin?
2. Would a downgrade to 2026.4.12 (last-known-good) be expected to resolve, or did the stack ship an SDK bump earlier?
3. Happy to provide raw log excerpts or run diagnostic patches if useful.