Bug: StdioServerTransport doesn't handle stdin close/end — causes zombie process accumulation

[ElliotDrel]

Summary

StdioServerTransport does not listen for stdin close or end events. When an MCP client closes its window or restarts, it drops its end of the stdio pipe — but the server process never detects this and keeps running indefinitely. Over time, with multiple client sessions, this causes unbounded zombie process accumulation.

The bug

In src/server/stdio.ts, the start() method attaches listeners for data and error, but not for close or end:

// src/server/stdio.ts — start() method
this._stdin.on('data', this._ondata);
this._stdin.on('error', this._onerror);
// ← no 'close' or 'end' listener

When the MCP client (e.g. Claude Code) closes its window, it closes its end of the stdin pipe. Node.js fires stdin.on('close') and stdin.on('end') on the server side — but since nothing is listening, the server process keeps running forever.

Real-world impact

Tested with Claude Code (3 concurrent windows) using two MCP servers built on this SDK:

• After one day of normal use: 37 orphaned google-tools-mcp processes, oldest consuming 26,807 CPU-seconds
• 9 orphaned gbrain processes after a few session restarts
• Machine became unresponsive; only manual taskkill cleared them

This is reproducible: close any Claude Code window and the MCP server process it spawned will remain running until the machine reboots.

Why SIGTERM doesn't help

The common suggestion is "handle SIGTERM" — but this doesn't solve it:

1. On Windows, SIGTERM is not delivered to child processes when a parent exits. Orphaning is guaranteed on Windows regardless of signal handlers.
2. On all platforms, when a stdio MCP client closes its connection (not the whole process), no signal is sent at all — only the pipe closes. The stdin close/end event is the only reliable cross-platform shutdown signal.

Note: PR #1568 addressed stdout EPIPE errors (client abruptly disconnecting mid-write), but left stdin disconnection unhandled.

The fix

In StdioServerTransport.start(), add two listeners:

async start(): Promise<void> {
  if (this._started) {
    throw new Error("StdioServerTransport already started! ...");
  }
  this._started = true;
  this._stdin.on("data", this._ondata);
  this._stdin.on("error", this._onerror);

  // Exit when the MCP client closes the pipe (window closed, session restarted, etc.)
  // This is the only reliable cross-platform shutdown signal for stdio servers.
  this._stdin.on("close", () => this.onclose?.());
  this._stdin.on("end", () => this.onclose?.());
}

And in close(), clean them up:

async close(): Promise<void> {
  this._stdin.off("data", this._ondata);
  this._stdin.off("error", this._onerror);
  this._stdin.off("close", this._onclose);  // add cleanup
  this._stdin.off("end", this._onend);      // add cleanup
  // ... rest of existing close() logic
}

Impact

This is a universal issue — every stdio MCP server built on this SDK is affected. Fixing it here protects all downstream servers without requiring changes in each one individually. The fix is two lines in start().

Environment

• SDK version: 1.29.0 (latest)
• OS: Windows 11 (worst case — SIGTERM not delivered), but reproducible on all platforms
• MCP client: Claude Code
• Affected servers confirmed: google-tools-mcp, gbrain, and any other server using StdioServerTransport

[ElliotDrel]

Related issues tracking similar stdio/process lifecycle problems:

Same root cause (stdin/process shutdown):

• [MCP-SDK] stdio client crashes with "MCP error -32000: Connection closed" when spawned server exits unexpectedly #1049 - stdio client crashes when server exits unexpectedly
• onerror and other listener not remove after client close (stdio) #780 - listener not removed after client close (stdio)
• StdioClientTransport does not follow the spec on close #579 - StdioClientTransport doesn't follow spec on close
• StdioClientTransport kills server unceremoniously (preventing ordered shutdown) #532 - StdioClientTransport kills server unceremoniously (preventing ordered shutdown)
• StdioClientTransport.close() doesn't terminate child processes, causing memory leaks #885 - StdioClientTransport doesn't terminate child processes, causing memory leaks
• Running MCP tools from Docker doesn't properly terminate the container #547 - Running MCP tools from Docker doesn't properly terminate the container
• The MCP client using a tool launched with uvx does not terminate. #320 - MCP client doesn't terminate
• Unable to cleanly shutdown/close MCP Server #113 - Unable to cleanly shutdown/close MCP Server

Related upstream fix:

• fix: handle EPIPE errors in StdioServerTransport to prevent process crash #1568 - Unhandled EPIPE error handling (similar pattern for stdout)

Similar PR attempts:

• fix: async onclose, stdin EOF detection, SIGTERM in examples #1814 - stdin EOF detection and SIGTERM handling
• feat(server): add host process watchdog to StdioServerTransport #1712 - host process watchdog for orphan detection
• fix(stdio): close server transport on stdin EOF #1613 - close server on stdin EOF