Switching renderers via /tui kills stdio plugin MCP server without restart (v2.1.215)

Summary

Switching the renderer in-session via /tui fullscreen (or /tui default) relaunches the CLI process in place (--resume <session-id>) and, as part of that relaunch, sends SIGINT to any installed plugin's stdio MCP server. The relaunched process is expected to restart that server — the way MCP servers come up on a normal cold launch. On one occasion the restart never happened: the server was killed and never came back, /mcp showed it as ✘ failed, and the session silently lost every tool that server provided until a manual /mcp → Reconnect.

This appears to be an intermittent race in the post-relaunch MCP restart path, not a deterministic failure of the /tui switch (see the reproduction section — 7/7 consecutive switches restarted cleanly on the same version).

Environment

• Claude Code v2.1.215
• macOS 26.2 (Darwin 25.2.0)
• Running inside a tmux 3.6a pane (terminal emulator: Ghostty)
• A local stdio MCP server (a TypeScript script executed by Bun), configured via an installed plugin
• Fullscreen renderer research preview enabled

Steps to reproduce

1. In a project that has an installed plugin providing a stdio MCP server, confirm the server is connected (/mcp shows it healthy).
2. In-session, type /tui fullscreen (or /tui default) to switch renderers. This relaunches the CLI in place via --resume <session-id> and SIGINTs the plugin's stdio MCP server.
3. After the relaunch, check /mcp and the per-generation MCP debug logs at

~/Library/Caches/claude-cli-nodejs/<project-slug>/mcp-logs-*/**.jsonl.

Observed behavior

• On the failing occurrence (v2.1.215, 2026-07-18, classic → fullscreen): the MCP debug log recorded the SIGINT to the server process, but the relaunched process never restarted the server. No reconnection was ever attempted. /mcp reported the server as ✘ failed, and the session lost all of that plugin's tools. The reverse switch (fullscreen → classic) restarted the server cleanly in ~1s.
• There is no user-visible error at switch time when this happens — the only way to notice is to open /mcp or read the debug logs.

Expected behavior

After the /tui relaunch, plugin stdio MCP servers should reconnect the same way they start on a first (cold) launch. A SIGINT during the relaunch is fine, but the relaunched process must reliably bring the server back up (or surface a visible error and attempt reconnection if it can't).

Reproduction attempt / determinism

I tried to reproduce deterministically on the same version (v2.1.215, 2026-07-19) in a fresh minimal project: 7 consecutive in-session /tui switches (4× classic → fullscreen, 3× fullscreen → classic), one trial with an inbound plugin-tool notification/message in flight at switch time. Each was verified via the per-generation MCP debug logs and the process table.

Every one of the 7 switches produced the healthy sequence:

"Sending SIGINT to MCP server process"
  → "MCP server process exited cleanly"
  → new server PID under the relaunched CLI
  → "Successfully connected (transport: stdio)"   [3.1–4.4s]

• Result: 0/7 wedges. 4/4 clean on classic → fullscreen, 3/3 clean on fullscreen → classic.
• The reconnect latency I saw (3.1–4.4s) was consistent regardless of switch direction. A cold first launch connected much faster (~0.5s); the difference looks like launch-vs-resume, not switch direction.

So the failure is intermittent — a rare race in the restart path — rather than a reliable property of the classic → fullscreen direction. Combined with the single original occurrence, please frame this as a race condition, not a deterministic defect.

Impact

Any automation or tooling wired into the session through an MCP server silently loses all of its tools when this race fires. Because there's no error at switch time, an unattended or long-running session can keep operating for a long time believing its tools exist when they're gone — the loss is only discoverable via /mcp or the debug logs.

Related quirks worth noting

1. /tui persists the renderer choice into settings.json ("tui": "fullscreen"). One in-session switch therefore silently changes the default renderer for all future sessions using that config directory — which may be surprising if the user only meant to switch the current session.
2. As above, the wedge is silent — no error is shown at switch time. Detection requires /mcp or the debug logs. A visible warning when a server fails to restart after a /tui relaunch would make this class of failure far easier to catch.