MCP servers (context7, playwright, pdf-viewer) stuck in respawn loop, old processes never cleaned up -- 58+ orphaned node.exe over ~13h (Windows)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 28, 2026

Environment: Windows 11, Claude Code (local session, long-running)

What happened:
Three MCP servers configured for a session -- @upstash/context7-mcp, @playwright/mcp, and @modelcontextprotocol/server-pdf -- repeatedly failed to establish/maintain their connection and were respawned by the harness roughly every 10-70 minutes over a 13-hour span, without the previous attempt's process being terminated. This left 58 orphaned node.exe processes accumulated by the time I checked (verified via Get-CimInstance Win32_Process -Filter "Name='node.exe'", cross-referencing CommandLine -- plain tasklist doesn't show enough to tell these apart from anything else).

Two other MCP servers on the same session/machine -- @supabase/mcp-server-supabase and a custom local server -- connected exactly once and stayed stable for the same 13-hour window, with zero respawns. This suggests the issue is specific to how context7/playwright/pdf-viewer establish or maintain their connection, not a general MCP-process-cleanup bug.

Evidence (waves observed, each ~6 processes: cli-wrapper + worker x 3 tools):
8:11 PM, 8:58 PM, 9:09 PM, 9:20 PM, 10:35 PM, 3:11 AM, 3:18 AM, 4:38 AM, 4:48 AM, 9:15 AM, 9:20 AM -- new waves kept appearing even minutes after manually killing the prior batch, confirming this is an active, ongoing reconnect loop, not a one-time backlog.

How this differs from #66280 (closed): that report describes one MCP server process spawned per Task-subagent, never reaped, scaling with subagent count (macOS, context7/snyk/playwright). This report is a different mechanism: no subagents were involved in triggering the respawns -- it's the top-level session's own connection to 3 specific servers repeatedly failing and retrying, with 2 other MCP servers on the identical session staying perfectly stable the whole time (ruling out "one process per subagent" as the cause here). Possibly the same underlying reaper gap, but a distinct trigger. Also possibly related: #1935, #22612, #39170, #40667, #45146 -- general orphaned-MCP-process reports.

Impact: unbounded process/memory growth over a long-running session; the 3 affected tools never actually became available/usable during this window despite repeated respawn attempts.

Workaround used: manually identify and kill all but the newest wave of each tool's processes, grouping by parsed CommandLine (a naive "kill all node.exe" risks killing an unrelated live connection).

View original on GitHub ↗