[BUG] Remote HTTP MCP server never re-probed after a transient network drop; misreported as UNKNOWN_CERTIFICATE_VERIFICATION_ERROR

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?

A remote MCP server configured over Streamable HTTP is marked disconnected after a transient network interruption (a VPN session expiring) and is never re-probed for the remainder of the process. All of its tools stay unavailable. Connectivity returning does not help, and neither does waiting.
The failure is surfaced as a certificate verification error, which is misleading: no certificate was validated or rejected. Measured from the same machine while the server was marked unreachable, two internal hosts behind the same VPN both resolved and completed full TLS handshakes with valid certificates in roughly 0.3s each. A deliberate junk-port control failed as expected, confirming the probe distinguishes reachable from unreachable rather than passing everything. DNS, routing, and TLS were all healthy at the moment of the error.
A likely mechanism: the VPN expiry drops the socket, and a truncated handshake where no certificate is ever offered gets reported through the certificate-error path. The wrong error text has a real cost — it sends the reader into network, VPN, and TLS-interception diagnosis, which is where the investigation went and where it found nothing.

What Should Happen?

A disconnected HTTP MCP server should be re-probed rather than latched as terminal for the process lifetime, ideally with backoff, so the tools return once connectivity does.
Where the server is a stateless request/response endpoint — one JSON-RPC POST in, one response out, no session id and no persistent stream — a retry is idempotent and carries no replay or half-open-stream risk. That is the case here.
Failing that, transport failure should be distinguished from certificate failure in the surfaced message, and if automatic reconnect is out of scope the text should say so ("connection lost, restart required") so the workaround is discoverable rather than folklore.

Error Messages/Logs

48 deferred tools are no longer available (MCP server disconnected): mcp__<server>__* (48)
<server> (UNKNOWN_CERTIFICATE_VERIFICATION_ERROR): "unknown certificate verification error"

Steps to Reproduce

1. Configure a remote MCP server over Streamable HTTP ("type": "http"), reachable only via VPN, and confirm its tools are available in an active session.
2. Let the VPN session expire mid-session, or drop the network interface, while the session stays open.
3. Attempt any tool call from that server. It fails and the server is marked disconnected with the certificate error above.
4. Reconnect the VPN and confirm the host is reachable again from the same machine (curl -sS -o /dev/null -w '%{http_code} %{time_appconnect}\n' https://‹host›/).
5. Attempt a tool call from that server again — still unavailable. Waiting does not change this.
6. Restart Claude Code. Tools are available immediately.

Note: step 2 is not deterministic on a timer, since it depends on VPN session lifetime. Forcibly dropping the network interface, or blackholing the route to the MCP host for ~30s and then restoring it, should exercise the same path.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.258 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Not duplicates: #82202 (Linux CA bundle, never connects at all), #67186 (stdio, closed stale, /mcp recovered it there), #82004 (deferred-tool staleness, different cause).