[Bug] MCP server processes spawned by Task subagents are not reaped (resource leak)

Bug Description
Claude Code — MCP server processes spawned by Task subagents are not reaped (resource leak over long sessions) Environment: Claude Code CLI on macOS (darwin), long session with many Task-tool subagents. Summary: Over one long multi-subagent session, orphaned MCP server processes piled up and noticeably slowed the machine ("glitching"/perceived hangs). Observed (single session): ~30 orphaned MCP node processes — context7-mcp x12, snyk x12, playwright-mcp x6 — plus a couple of leftover background dev/preview servers I'd started. Total idle node processes ~22; killing the orphaned MCP + servers dropped it to 3. Trigger: each subagent that loads an MCP-backed tool via ToolSearch (Context7, Snyk, Playwright, ...) appears to spawn its OWN MCP server child process (npx-launched), and these are NOT terminated when the subagent completes. Across dozens of subagents in one session they accumulate; the per-MCP count roughly tracks the number of subagents that used that MCP. Impact: RAM/CPU pressure, perceived slowness/hangs; the user noticed and asked me to clean up. Repro: run a long session with many Task subagents, each using ToolSearch to load an MCP tool (Context7 for docs, Snyk for scans, Playwright for screenshots). Watch pgrep -fl mcp grow; the processes persist after the subagents finish. Expected: subagent-spawned MCP servers should be reaped when the subagent (or at least the session) ends; OR a single shared MCP server instance should be reused across subagents instead of one-per-subagent. Secondary: Bash background processes (run_in_background and &-launched dev/preview servers) also persist for the whole session with no lifecycle/reaper — a session-end cleanup or clearer ownership would help. Workaround used: pkill -f 'context7-mcp' / 'playwright-mcp' / 'snyk' + kill leftover servers (the harness respawns MCP on demand).

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.168
• Feedback ID: 1420ac4e-6b66-48ce-9f46-4e20aab14963

Errors

[]