0.41.0: crash-loop leaves orphaned MCP child processes — CPU/RAM spike (30%/3.3GB, 251 processes) #139

Bug: wmux 0.41.0 — runaway process count / crash-loop leaves orphaned MCP child processes, huge CPU/RAM spike

Version: 0.41.0 (Windows, downgraded back to 0.38.0 as workaround)
OS: Windows 10 Pro 10.0.19045

Symptom

Shortly after updating to 0.41.0, Task Manager showed the wmux process group consuming 30.9% CPU and ~3.3 GB RAM across 251 grouped processes. Expanding the group showed it was almost entirely made of individual node.exe ("Node.js JavaScript Runtime") child processes, each relatively small (24–83 MB), but summing up massively due to sheer count. Windows Defender also flagged the sudden burst of process activity.

Screenshot of the Task Manager view (collapsed + expanded groups) available on request.

Likely root cause

Each wmux pane that runs a claude (Claude Code CLI) session spawns its own independent set of MCP-server node.exe child processes (in my setup: 6 MCP servers per session — amocrm-mcp, mpstats-mcp, imap-email-mcp ×2, mcp-google-sheets, google-tasks-mcp-server). These are not shared/reused across panes or sessions.

Between 12:38 and 13:10 (local time) on the day of the incident, 6 separate wmux crash dumps were written to %LOCALAPPDATA%\CrashDumps:

wmux.exe.3700.dmp   12:38
wmux.exe.32120.dmp  12:48
wmux.exe.22636.dmp  12:52
wmux.exe.30344.dmp  13:00
wmux.exe.18400.dmp  13:01
wmux.exe.11612.dmp  13:10

This strongly suggests wmux 0.41.0 was crash-looping — repeatedly crashing and auto-restarting (or restoring the previous session) — and on each restart it re-spawned a fresh batch of panes/CLI sessions (each pulling in its own set of MCP node child processes) without cleaning up the orphaned processes from the previous crashed instance. Over ~30 minutes this accumulated into 251 leftover node.exe processes.

Steps to reproduce (best guess, not fully confirmed)

1. Update wmux to 0.41.0 with an existing multi-pane session that runs Claude Code (with several MCP servers configured in ~/.claude / .mcp.json).
2. Restart / let wmux restore the session.
3. If wmux crashes and auto-restarts (see crash dumps), observe node.exe process count climbing with each crash cycle instead of being cleaned up.

Expected behavior

• wmux (or the terminal/pane host) should terminate child processes (including MCP server subprocesses spawned by CLI tools running in panes) when a pane/session is torn down or when wmux crashes and restarts.
• A crash-loop should not be able to unboundedly multiply subprocess count.

Workaround

Rolled back to 0.38.0 via the cached installer left by the updater, which does not reproduce the issue.

Attachments available on request

• Task Manager screenshot (collapsed + expanded process group)
• Crash dump files (%LOCALAPPDATA%\CrashDumps\wmux.exe.*.dmp, ~5.3–5.8 MB each)