fix: handle stale MCP client reconnection to prevent persistent EOF errors

[w495604217]

Problem

When the HTTP transport to the Chrome extension drops (e.g., browser restart, extension reload, network interruption), the singleton mcpClient in mcp-server-stdio.ts becomes permanently unusable.

Root cause: ensureMcpClient() catches ping() failures in the outer try-catch, which closes the client and sets it to null — but subsequent calls may still fail because the error is silently swallowed (the function returns undefined instead of throwing). Additionally, handleToolCall() has no retry logic, so a single transient connection error immediately returns an error to the caller.

This causes persistent connection closed: EOF / client is closing: EOF errors that can only be resolved by restarting the entire MCP server process.

Fix

1. Independent ping error handling — ping() failures are now caught separately and fall through to client rebuild, instead of being caught by the outer try-catch
2. Explicit old client cleanup — always close() the old client before creating a new one
3. forceNew parameter — allows callers to explicitly request a fresh client
4. Automatic retry in handleToolCall() — connection-related errors (EOF, closed, ECONNREFUSED, fetch failed, client is closing) trigger one automatic retry with a freshly built client
5. Error re-throw — connection errors are re-thrown instead of silently swallowed

Testing

Verified with multiple MCP clients (Antigravity, custom Node.js clients) that the patched server correctly recovers from:

• Chrome browser restarts
• Extension reloads
• Network interruptions
• Long idle periods where the HTTP connection times out

[adhimiw]

nice

[juanroldanbrz]

Amazing! Athough:

PR #301 (PyEL666) — Cleaner variant: just removes the caching from getMcpServer() itself, making it a factory. Only changes mcp-server.ts, no changes needed to server/index.ts. Open since Feb 22.