VSCode extension: switching Claude Code session tabs spawns duplicate MCP server processes without terminating old ones

Summary

Switching between Claude Code conversation sessions/tabs inside the VSCode extension causes MCP server processes (e.g. the Serena plugin) to accumulate — each tab switch spawns a brand new MCP server connection without terminating the previous one. Over a single VSCode window session this leaves multiple orphaned MCP server processes running side by side, visibly stacked as duplicate icons in the tab bar.

Environment

• Claude Code as a VSCode native extension (not the standalone CLI)
• Windows 11
• Observed with the Serena MCP plugin (serena@claude-plugins-official), but the mechanism looks generic to any MCP-backed plugin, not Serena-specific

Steps to reproduce

1. Open a project with an MCP plugin enabled (e.g. Serena) in the VSCode extension.
2. Start a Claude Code conversation — the plugin's MCP server connects normally.
3. Open a new conversation tab / switch to a different session tab within the same VSCode window.
4. Repeat step 3 a few times.
5. Check running processes (tasklist on Windows) for the plugin's MCP server binary.

Expected behavior

Switching away from a session tab should either reuse the existing MCP connection or cleanly terminate it before/instead of spawning a new one — same as what already happens on a full VSCode window reload (see below).

Actual behavior

Each session-tab switch starts a new MCP connection for the plugin without closing the old one. Confirmed via tasklist:

serena.exe   PID 20136
serena.exe   PID 12416
serena.exe   PID 2672

Three live serena.exe processes accumulated from switching tabs in one window, alongside three claude.exe helper processes (one per open session tab). The user visually noticed this as duplicate plugin icons stacking side by side in the tab bar.

Log evidence

From Claude VSCode.log (extension host log), no Terminating MCP server process tree / connection closed entries appear between these two connection starts — the first is simply never torn down:

2026-08-05T17:11:27.943Z [DEBUG] MCP server "plugin:serena:serena": Starting connection with timeout of 30000ms
2026-08-05T17:11:34.586Z [DEBUG] MCP server "plugin:serena:serena": Successfully connected (transport: stdio) in 6644ms

... (session tab switched, ~10 minutes later, no teardown of the above) ...

2026-08-05T17:21:45.755Z [DEBUG] MCP server "plugin:serena:serena": Starting connection with timeout of 30000ms
2026-08-05T17:21:49.960Z [DEBUG] MCP server "plugin:serena:serena": Successfully connected (transport: stdio) in 4206ms
2026-08-05T17:21:50.610Z [DEBUG] MCP server "plugin:serena:serena": Starting connection with timeout of 30000ms
2026-08-05T17:21:55.603Z [DEBUG] MCP server "plugin:serena:serena": Successfully connected (transport: stdio) in 4995ms

Notably, the cleanup logic does exist somewhere: a full VSCode "Developer: Reload Window" produces a brief startup session followed by a resume session, and in that specific case the first (throwaway) connection is cleanly torn down a few seconds later:

2026-08-05T17:11:35.973Z [DEBUG] MCP server "plugin:serena:serena": Terminating MCP server process tree
2026-08-05T17:11:36.438Z [DEBUG] MCP server "plugin:serena:serena": UNKNOWN connection closed after 6s (cleanly)

So the teardown path exists for the startup→resume handoff on reload, but is not applied when switching between session tabs within the same window without a reload.

Impact

• Orphaned MCP server processes accumulate for as long as the VSCode window stays open, wasting memory/CPU and (for slower-starting MCP servers) repeatedly paying startup cost.
• For MCP servers that open their own side-channel ports/dashboards (Serena opens a local web dashboard on an auto-incrementing port per instance), this also leaks listening ports over a session.

Suggested fix direction

When a session tab loses focus / a different session tab becomes active within the same window, either:

• reuse the already-connected MCP server instance for plugins shared across tabs, or
• apply the same teardown (Terminating MCP server process tree → clean close) already used in the reload startup→resume handoff.