VS Code extension: /mcp reconnect and MCP servers panel intermittently fail with "terminal is still starting up or is showing another view"

Title

/mcp reconnect (and the Customize → "MCP servers" panel's Reconnect button) intermittently fail with "MCP controls aren't available right now — the terminal is still starting up or is showing another view" in the VS Code extension

Environment

• Claude Code VS Code extension: 2.1.220 (win32-x64)
• OS: Windows 11 Pro 10.0.26200
• Node: v20.15.0 / npm: 10.7.0 (upgraded to 10.9.9 as part of diagnosing this — see note below)

Summary

Both the chat-typed /mcp reconnect command and the native "MCP servers" panel (opened via / → Customize → MCP servers → per-server Reconnect button) route through the same guarded reconnect handler in the bundled claude.exe. That handler requires two module-level references (set via what appears to be a useEffect-registered pair, referred to below by their minified names d5s/p5s) to be populated before /mcp reconnect or panel-triggered reconnects can run. These references appear tied to the CLI's interactive-terminal (ink) render lifecycle — set when a particular "screen" mounts, cleared (p5s()) when it unmounts or another view takes over.

In the VS Code extension, the CLI is driven headlessly over an IPC/JSON protocol rather than through a real TTY, and observed behavior indicates this registration is either never reliably established or gets cleared during normal extension use (e.g. while other panel views are shown). The result: /mcp reconnect fails with a generic, unhelpful error that gives the user no indication of why — they're told to check terminal/config, but the actual servers are healthy and reachable.

Evidence

• Grepping strings directly from resources/native-binary/claude.exe in the installed extension shows the guard:

``
let c=xFo(),u=wYd();if(!c||!u)return a2("MCP controls aren't available right now — the terminal is still starting up or is showing another view.");
`
where xFo()/wYd() just return two module-level vars (c5s/u5s) set via d5s(e,t){c5s=e,u5s=t} and cleared via p5s(){c5s=null,u5s=null}`.

• The same guard is hit by the extension-host's own onMcpReconnect RPC handler (used by the webview's "MCP servers" panel Reconnect button — request type reconnect_mcp_server), not just the typed slash command. So the panel is not a reliable workaround; it shares the same failure mode.
• Extension logs (Claude VSCode.log) show the typed command failing with this exact message well after the extension had been running for 10+ minutes — ruling out a simple "still starting up" race on process spawn. The panel-triggered reconnect request did succeed at least once in the same session, indicating the underlying state flips between populated/null during normal use rather than being permanently unset.
• Separately (and now resolved on my end, unrelated to the extension itself): 3 of 4 configured MCP servers were also failing to connect at startup due to an npm 10.7.0 arborist race condition (Cannot set properties of null (setting 'peer')) when multiple npx-based MCP servers (@playwright/mcp, @upstash/context7-mcp) install concurrently at extension startup and race on the shared npm cache. Upgrading to npm 10.9.9 fixed that separately. This is mentioned only to make clear it's a distinct issue from the reconnect-control failure above — the reconnect UI is broken independent of whether the underlying servers are healthy.

Repro

1. Open a project with 2+ MCP servers configured (stdio or plugin-provided) in VS Code with the Claude Code extension.
2. Let one or more servers fail to connect (any transient failure works, e.g. temporarily block outbound network for one server).
3. In the Claude Code panel, type /mcp reconnect all, or use / → Customize → "MCP servers" → click Reconnect on a specific server.
4. Observe: intermittently, this returns "MCP controls aren't available right now — the terminal is still starting up or is showing another view" instead of attempting a reconnect — even many minutes into a normal session with the panel actively in use.

Expected

/mcp reconnect and the MCP servers panel's Reconnect button should reliably work in the VS Code extension context, since the extension doesn't provide a real interactive terminal for the CLI's TUI-mount-gated logic to depend on. The reconnect handler should not require the ink-UI mount state at all when invoked via the extension's non-interactive driving mode — or if it must, the extension should ensure that state is always populated in this mode rather than leaving it to an internal render lifecycle that isn't guaranteed to run.

Suggested fix direction

Either:

• Decouple the reconnect/enable/disable MCP handlers from the ink-UI mount state entirely when running under the extension's headless/IPC-driven mode (there's likely already a flag distinguishing "interactive TTY" vs "IDE-driven" mode that could gate which code path registers the handler), or
• Ensure the handler registration happens once at CLI process startup regardless of which "screen" is showing, rather than only within a specific mounted component's effect.