[BUG] Recurring "RangeError: Maximum call stack size exceeded" when closing SSE server connections, causing repeated crashes

[g-pc-info]

Description

mcp-hub repeatedly hits RangeError: Maximum call stack size exceeded when closing SSE server connections. This appears to trigger an unhandled exception that crashes the process, causing frequent restarts under a process manager (pm2).

Environment

• mcp-hub version: 4.2.1
• Node.js version: 24.14.1
• OS: Linux (Raspberry Pi, Debian-based)
• Process manager: pm2 (fork mode)
• Config: multiple stdio + SSE/proxy servers, including a mcp-remote-based connection

Frequency

Over ~4 days of uptime:

• Total lines in error log: 262,808
• Occurrences of Maximum call stack size exceeded: 51,486 (~20% of all log lines)
• Breakdown by source:
  • Error closing server connected to Unknown: Maximum call stack size exceeded — 16,367 occurrences
  • Error closing server connected to claude-ai (via mcp-remote 0.1.37): Maximum call stack size exceeded — 109 occurrences
• pm2 restart count over the same period: 9

Stack trace (representative sample)

{"type":"warn","message":"Error closing server connected to Unknown: Maximum call stack size exceeded","data":{},"timestamp":"2026-07-07T21:17:36.204Z"}
Exception in PromiseRejectCallback:
file:///home/rpirt/.npm-global/lib/node_modules/mcp-hub/dist/cli.js:165
...
RangeError: Maximum call stack size exceeded

Exception in PromiseRejectCallback:
file:///home/rpirt/.npm-global/lib/node_modules/mcp-hub/dist/cli.js:151

The trace points into the bundled MCP SDK's SSEServerTransport/close-handling code inside dist/cli.js (minified, so exact line numbers aren't meaningful, but the surrounding logic is the transport's close() / onclose callback chain).

Suspected cause

Based on the log pattern, it looks like closing an already-unstable or already-closing SSE connection triggers the onclose handler to re-invoke close(), which re-invokes onclose, forming a recursive loop until the call stack overflows. This becomes an unhandled uncaughtException/unhandledRejection, which crashes the whole hub process rather than just the one server connection.

Impact

Since this crashes the entire mcp-hub process (not just the individual failing server), all other connected MCP servers become unavailable until pm2 restarts it. In our setup this happens roughly every few hours.

Workaround

We've set up a daily cron-based pm2 restart mcp-hub as a stopgap, but this doesn't address the underlying recursive close bug.

Request

Would appreciate any guidance on:

1. Whether this is a known issue in the bundled MCP SDK version
2. Whether isolating a single failing server's close error from crashing the whole process (rather than propagating as an unhandled rejection) would be an acceptable direction for a fix