v2.1.142 disconnects on remote-SSH after extension update — claude binary accumulation + MCP server flapping

Environment

• VS Code extension: anthropic.claude-code-2.1.142-linux-x64
• VS Code mode: Remote-SSH (client macOS, server Linux 6.12 / Debian 13)
• Conversation type: long-running (multi-hour, large context — multi-batch code edits)
• Started: after upgrading to v2.1.142

Symptom

The chat panel repeatedly disconnects from the remote claude binary mid-conversation.

• After the first few disconnects, a Developer: Reload Window would briefly reconnect.
• Sending the message "continue" reliably triggered a fresh disconnect.

Observable evidence

On the remote host, ps -eo pid,ppid,rss,etime,comm | grep claude showed three separate native-binary claude processes running concurrently, all spawned by the same extensionHost PID (anthropic.claude-code-…/resources/native-binary/claude), each ~200-250 MB RSS. All three started within seconds of each other (etime 39s / 43s / 46s) which lines up with the disconnect → reconnect cycle. Pattern: on disconnect the extension spawns a new claude process without terminating the previous one. A pkill -f "anthropic.claude-code.*native-binary/claude" from a plain SSH session followed by Developer: Reload Window cleared the accumulation, but the disconnects resumed under continued use.

Also observed: in-session system reminders kept reporting that the mcp__claude_ai_Gmail__*, mcp__claude_ai_Google_Calendar__*, and mcp__claude_ai_Google_Drive__* MCP tools were going "disconnected" then "available again" every few turns. I have not enabled any of these MCP servers in my client — they appear to be provided by the extension or by claude.ai's connector layer. The flap timing correlates with the disconnects on "continue".

Hypothesis

In a long-running conversation with significant transcript state, the extension's reconcile path appears to crash or stall when MCP-server-state churn happens concurrently with a user turn, and a new claude binary is spawned without releasing the prior one. The disconnect-then-respawn pattern is what I'd expect from an unhandled exception in the extension host serializing/replaying that state.

Repro steps

I don't have a clean local repro yet — happens under real workload (long edit sessions, 10+ tool calls per turn). Will update if I find a tighter trigger.

Workarounds that helped

1. pkill -f "anthropic.claude-code.*native-binary/claude" from a separate SSH session, then Developer: Reload Window in VS Code — clears process accumulation.
2. Starting a fresh conversation (small context) — no disconnects.

Ask

• Confirm whether the extension is expected to spawn a fresh claude binary on reconnect rather than reattach.
• Are the claude_ai_Gmail / Google_Calendar / Google_Drive MCP servers shipped/managed by the extension itself? If so, can their reconnect cadence be inspected / suppressed?
• Any logs I can capture to make this more useful?

---

Filed by Claude Opus 4.7 (1M context) on behalf of the user (@timoteicampian). Observations and process-inspection commands were performed inside the same affected session.