Windows: http-first initialize hangs 60s with no response; same server works on macOS and via a POST-only client

[istefox]

Summary

On Windows, Claude Desktop via mcp-remote 0.1.37 (transport strategy http-first) sends initialize to a StreamableHTTP server, gets no response, and times out after 60 seconds with MCP error -32001: Request timed out. The same server config answers an initialize from mcp-remote 0.1.37 in a few milliseconds on macOS, and a POST-only client answers fine against the same server on the same Windows machine. The hang also reproduces against a second, unrelated MCP server on that machine. This points at mcp-remote on Windows rather than any single server.

Reported downstream at istefox/obsidian-mcp-connector#300, which has the full user logs.

Environment (reporter, Windows)

• mcp-remote 0.1.37
• Claude Desktop 1.12603.1
• Node.js under Program Files\nodejs, launched via cmd /c npx -y mcp-remote URL --header "Authorization: Bearer ..."
• Server: stateless MCP server (StreamableHTTPServerTransport, sessionIdGenerator: undefined, enableJsonResponse: true), returns 405 on GET so the SSE stream is skipped.

Client initialize payload (from Claude Desktop)

{"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{"extensions":{"io.modelcontextprotocol/ui":{"mimeTypes":["text/html;profile=mcp-app"]}}},"clientInfo":{"name":"claude-ai","version":"0.1.0"}},"jsonrpc":"2.0","id":0}

Windows mcp-remote output (hang)

Using transport strategy: http-first
Connected to remote server using StreamableHTTPClientTransport
Local STDIO server running
Proxy established successfully between local STDIO and remote StreamableHTTPClientTransport
[Local→Remote] initialize
[Local→Remote] notifications/cancelled
Shutting down...

No [Remote→Local] 0 ever appears. 60 seconds elapse between initialize and notifications/cancelled.

What I could and could not reproduce

On macOS (Node 22.23.0), with the same mcp-remote 0.1.37 and a minimal server matching the config above, the handshake completes:

[Local→Remote] initialize
[Remote→Local] 0
{"jsonrpc":"2.0","id":0,"result":{...}}

in about 3 ms. I do not have a Windows machine to reproduce on, so the Windows logs are from the downstream reporter.

Ruled out

• Not the server: a POST-only client works against it on the same Windows box, and macOS works through mcp-remote.
• Not one server's code: the same hang appears on a second, unrelated server on the same machine.
• Not the protocol version: 2025-11-25 negotiates fine on macOS.

Ask

Is this a known issue with http-first on Windows? Is there anything in how the StreamableHTTP POST response is read on Windows (keep-alive, chunked read, undici) that would explain a 60-second no-response on initialize specifically? I am happy to run a debug build or capture more on the reporter's machine. A minimal macOS repro (server plus driver) is available on request.

[istefox]

Status update with a downstream reference. The reporter worked around this by dropping mcp-remote for a small POST-only stdio bridge, which connects Claude Desktop to the same server with no hang. I shipped that bridge and a short guide in my repo, and the originating issue, istefox/obsidian-mcp-connector#300, is now closed and confirmed working on Windows.

I'm leaving this open because the mcp-remote behaviour itself is unchanged: the 60-second initialize hang still happens with http-first on Windows, so the root cause is still worth chasing. I'm happy to share the macOS repro or run a debug build on the reporter's machine if that would help.

[istefox]

Quick follow-up: this still reproduces. A few days on, the http-first initialize hang on Windows is unchanged: 60 seconds, no [Remote→Local] 0, then a cancel. macOS still answers the same initialize in about 3 ms through the same mcp-remote 0.1.37.

I worked around it downstream by swapping mcp-remote for a small POST-only stdio bridge, shipped in obsidian-mcp-connector 0.21.5 (now 0.21.6), and the Windows reports cleared. So there's a usable path for anyone hitting this, but the mcp-remote behaviour itself is still the open question.

The minimal macOS repro (server plus driver) is still on hand, and I'm happy to run a debug build or capture undici/keep-alive traces on the reporter's Windows machine. Is there anything specific in the StreamableHTTP POST read path you'd want logged? Glad to help narrow it down.