Windows: MCP process trees are never reaped — PR #15516 is skipped on this platform, and stdio servers are eagerly started regardless of use #52251

This is Windows-specific follow-up evidence for the two behaviors described here, with measurements. It is not a duplicate of the process-tree mechanics — the fix in #15516 is explicitly skipped on Windows, so this platform has no reaping at all.

Setup

• Windows 11, 15.7 GB RAM
• 12 configured MCP servers: 4 type: "local" (stdio), 8 type: "remote" (HTTP)
• The local ones: playwright (cmd /c npx -y @playwright/mcp@latest), cloudflare (npx -y @cloudflare/mcp-server-cloudflare run <id>), notion (npx -y @notionhq/notion-mcp-server), fetch (uvx mcp-server-fetch)

Measurement 1 — remote vs local is the dividing line

With 8 remote servers configured, zero of them produced a local node.exe. The 8 local ones did. That part behaves as described in #30123.

Measurement 2 — one agent episode leaked +43 processes

Clean baseline: 376 processes. Ran one opencode run episode (~60s). Afterwards: 419.

The service crashed during this run. Across a longer session the same accumulation reproduced: 637 processes vs a 376 clean baseline, i.e. 19 uv.exe chains vs 7. Reboot cleared the 12 surplus chains.

Measurement 3 — duplicate spawn, matches #31554

node.exe command lines attributed:

The 9 other configured servers (github, tavily, firecrawl, brightdata, exa, context7, notion-remote, fetch, kimi-cu) contributed no node.exe. 2,414 MB total, from 2 of 4 local servers.

On a later occasion the same playwright server reached 52 concurrent copies / 4,892 MB, then dropped back to 1 on its own. So the multiplier is not stable at 2-4.

Why Windows has no mitigation

#15516 walks the descendant tree with pgrep -P and SIGTERMs each descendant before client.close(). The PR states it is skipped on Windows where pgrep is unavailable, so StdioClientTransport.close() signals only the direct child. On this platform the cmd /c wrapper exits early by design, leaving node grandchildren reparented and waiting on a closed stdin indefinitely.

#30123 already lists the fix directions. Concretely, what would help on Windows:

1. Replace the pgrep -P walk with a platform tree walk — e.g. build descendants from CreateToolhelp32Snapshot / Process32First on Windows, so fix: kill orphaned MCP child processes and expose OPENCODE_PID on shu… #15516's existing logic can be enabled there.
2. Handle the cmd /c case explicitly. cmd /c exiting early is expected; a bare descendant walk from the direct child is not sufficient once the wrapper is gone. taskkill /T /F /PID on the direct child at least reaches the tree.
3. Lazy stdio startup, per MCP server processes not cleaned up on exit (orphan processes) + eagerly starts all servers #30123. In the config above, notion runs alongside a separate notion-remote entry pointing at mcp.notion.com, so at least one local server is plausibly unnecessary — but eager start means it is launched regardless of whether the session ever calls it.

One process-level detail worth separating

The parent opencode.exe process itself also grows with conversation length and never releases: measured 489 → 537 → 621 → 699 → 1,308 → 1,869 MB over a single long session, monotonically, with no plateau. That is the session context heap, not the MCP leak, and it is not covered by the issues above. Reporting it only because it was conflated with the MCP leak for a while on my side and made attribution harder.