Remote Control + VS Code Remote-SSH: reconnect spawns a second `claude --resume` on the same session (duplicate instances, bridge drops, window exits)

Summary

With Remote Control enabled in the VS Code extension over Remote-SSH, a window reconnect (new device, network blip, or VS Code Server reconnection grace) starts a second claude --resume on the same session while the old one is still alive. Two instances then run the same conversation concurrently on the same working tree: both execute tool calls, both commit, both answer the user. Remote Control "drops" repeatedly, and the VS Code window that shows the session exits on its own after a while. We have no way to close "the extra window": it dies by itself, and the orphaned host keeps its claude process running for up to the 3-hour grace period.

Environment

• Claude Code 2.1.280 (VS Code extension anthropic.claude-code-2.1.280-linux-x64, native binary)
• VS Code 1.139.0, Remote-SSH to a Linux host (Ubuntu, kernel 7.0.0-gcp, x86_64)
• Remote Control enabled for a long-lived session (started 2026-08-30; transcript ~126 MB; ~2.6k bridge-session records for one bridgeSessionId)
• Session is resumed from more than one device (laptop / phone via Remote Control)

What happens (from ~/.vscode-server/data/logs/<ts>/ and ps)

1. A new window connects → a new extension host starts; the old connection logs "client has disconnected, will wait for reconnection (grace 3h)".
2. The new extension host runs claude --resume <same session id>; the old host's claude is still alive → two claude processes with the same session id.
3. Both pick up the same conversation state. Today (2026-09-23) the duplicate instance wrote and committed a change on our branch while the first instance was working on the next step; the first instance found "unexpected" uncommitted files and then "nothing to commit". No native lock prevents this.
4. Remote Control on the phone shows the bridge as connected, then loses it ("слетает") when the two instances fight over the same bridge session. The window itself later exits.
5. Over the last 30 days our own watchdog on the host had to kill 13 duplicate claude instances (almost every morning). A user cannot be expected to run a watchdog.

Expected

• One session id = one live instance. A second --resume (or the extension's reconnect path, v2.1.232+) should either attach to the running instance or refuse with a clear message.
• Remote Control should not start a parallel instance on reconnect; the bridge should re-attach to the existing process.
• If the extension host is orphaned by Remote-SSH, its claude child should not outlive the window that owns it.

Impact

Concurrent tool execution on one repository (double commits, races on files), repeated Remote Control disconnects, and windows that crash. For agentic work this is a correctness problem, not a UX nit.

What we checked

• Docs/changelog: no session lock in any version; reconnect-on-resume logic since v2.1.232; behaviour under Remote-SSH reconnect is undocumented. Related: #64756, #94743.
• Workarounds that only reduce frequency: closing the old window before opening a new one elsewhere ("Kill VS Code Server on Host"), lowering VSCODE_RECONNECTION_GRACE_TIME. None of them is acceptable when the window exits on its own.

Happy to provide sanitized logs from ~/.vscode-server/data/logs/ and the extension output channel on request.