Windows: remote HTTP MCP server times out (CONNECT_TIMEOUT) since 2026-10-02; same server and address connect from Claude Code on macOS[BUG]

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?

Since 2026-10-02 08:06 UTC, every Claude Code start on one Windows 11 laptop fails to connect to a remote HTTP MCP server with CONNECT_TIMEOUT after 30 s. The same server, at the same address and from the same account, connects instantly from Claude Code 2.1.265 on macOS. The Windows laptop itself connected without trouble until 2026-10-01 19:08 UTC. It fails in the desktop app's Code tab (2.1.286), in scheduled tasks, from the CLI with claude mcp list (2.1.246), and after a full Windows reboot.

Server: ha-mcp 8.6.0, the Home Assistant in-process MCP server, reached through a Home Assistant webhook over Nabu Casa remote UI (https://<instance>.ui.nabu.casa/api/webhook/mcp_<id>) with an Authorization header.

What Should Happen?

It should connect as it does from macOS, and as it did on this laptop until 2026-10-01: modern era, protocol 2026-07-28, in about 250 ms.

Error Messages/Logs

Windows client log until 2026-10-01 19:08 UTC (agent-sdk 0.3.284):
Successfully connected (transport: http) in 241ms
Connection established ... "serverVersion":{"name":"ha-mcp","version":"8.6.0"},"protocolEra":"modern","negotiatedProtocolVersion":"2026-07-28"

Every start since 2026-10-02 08:06 UTC (23 log files, zero successes):
Testing basic HTTP connectivity to https://<instance>.ui.nabu.casa/api/webhook/<id>
version negotiation probe failed on the http transport; reconnecting pinned legacy   (+~230 ms)
HTTP Connection failed after 30002ms: MCP server "<server>" connection timed out after 30000ms (code: CONNECT_TIMEOUT, errno: none)

With MCP_PROTOCOL_NEGOTIATION=legacy for one CLI run: no probe line, still times out after 30 s.

Server side (uvicorn access log behind the webhook), per Windows attempt, all answered in under 0.5 s:
POST 200   (probe)
POST 200   (legacy initialize)
POST 202   (notifications/initialized)
After that nothing more arrives from the client. No tools/list is sent. A successful modern connection, from the Mac or from this laptop before the failure, shows four 200 POSTs over two connections.

Steps to Reproduce

1. Windows 11 Pro 10.0.26300, Claude desktop app, Code tab, Claude Code 2.1.286.
2. A user-scope HTTP MCP server: type http, url https://<instance>.ui.nabu.casa/api/webhook/mcp_<id>, with an Authorization header.
3. Run claude mcp list, or start a Code session.
4. Result: CONNECT_TIMEOUT after 30 s. The same server and address from Claude Code 2.1.265 on macOS: Connected.

Apparent trigger: the server's host restarted 2026-10-02 08:05:43 to 08:06:02 UTC while the Windows client was dialing. The client got ECONNRESET, then one probe reached the webhook before it was registered. Every attempt since then has failed. Rebooting Windows and reloading the server changed nothing.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.284

Claude Code Version

2.1.286 (desktop app); CLI 2.1.246 fails the same way

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Ruled out:

• Server and route: macOS Claude Code connects through the same address, and a claude.ai connector to the same server works.
• Network: from the laptop, the host resolves, TCP 443 opens and the Home Assistant login page loads in a browser. Two different networks were tried, mobile and cable.
• Reboot: no change. Server integration reload: no change.
• Stored per-server state: the server entry in ~/.claude.json holds only type, url and headers. No mcp-discovery-cache on either machine.
• Version alone: the older CLI 2.1.246 fails on Windows, while 2.1.265 works on macOS.
• Remote switches: tengu_mcp_protocol_negotiation_http and tengu_mcp_stateless_skip_init are true on both machines.

Questions:

1. Why does the version negotiation probe fail from Windows against a server that negotiates 2026-07-28 from macOS?
2. Why does the legacy path hang after notifications/initialized instead of sending tools/list or failing fast?
3. Is there per-machine state, beyond what a reboot clears, that changed while the server was unreachable for about 20 seconds?