[BUG] VSCode extension: after extension host restart, restored chat tabs are not re-bound to sessions - messages silently dropped, infinite spinner, dead stop button (Windows)

Environment

• Claude Code 2.1.215 (VSCode extension, native binary), Windows 11 Pro 10.0.26200
• VSCode extension host restarted mid-day while 5+ chat tabs with active sessions were open (trigger in my case: another extension made the extension host unresponsive and it was restarted; the trigger doesn't matter — any exthost restart reproduces the state)

Summary

When the extension host restarts (crash, unresponsive-restart, or webview reload), all running Claude CLI processes are orphaned and exit uncleanly. The chat tabs are visually restored afterwards, but they are not re-bound to their sessions. A message typed into such a tab is silently dropped inside the webview — it never reaches the extension host (no io_message is logged), no CLI process is spawned, nothing is appended to the session .jsonl, and the UI shows a spinner ("Percolating…"/"Honking…") forever. The stop button is equally dead because there is no process or request behind the tab.

There is no error, no toast, no indication the session is detached. From the user's perspective the chat is just "stuck", and the natural reaction — retyping the request in another tab — risks double-executing work (in my case the request was a git commit + push).

Evidence (from logs, times local UTC+2)

main.log:

2026-07-21 12:12:29.790 [error] [UtilityProcess id: 2, type: extensionHost, pid: 17892]: crashed with code 1 and reason 'killed'

renderer.log:

2026-07-21 12:22:55.613 [info] Extension host (LocalProcess pid: 45096) is unresponsive.
2026-07-21 12:22:57.415 [warning] UNRESPONSIVE extension host: 'ms-python.python' took 60.6% ... saved PROFILE ...

exthost/Anthropic.claude-code/Claude VSCode.log — webview re-initializes and old channels die:

2026-07-21 12:22:59.201 ... {"type":"request", ... "list_remote_sessions"}   <- full webview re-init handshake
2026-07-21 12:22:59.280 ... {"type":"launch_claude","channelId":"gqh6yc2cpd", ...}
2026-07-21 12:23:07.221 [warning] Channel not found for logEvent: ozfhy3nkdw
2026-07-21 12:23:07.236 [info] Closing Claude on channel: ozfhy3nkdw
2026-07-21 12:23:07.457 [DEBUG] Prior session exited uncleanly: 1fce0699-... (v2.1.215)
2026-07-21 12:23:07.462 [DEBUG] Prior session exited uncleanly: 5fa29759-... (v2.1.215)
2026-07-21 12:23:07.468 [DEBUG] Prior session exited uncleanly: dd360455-... (v2.1.215)
2026-07-21 12:23:07.472 [DEBUG] Prior session exited uncleanly: b0bef34f-... (v2.1.215)
2026-07-21 12:23:07.477 [DEBUG] Prior session exited uncleanly: b41f9a60-... (v2.1.215)

Only the tab I happened to keep using got a new process (--resume=<its-session-id> visible in the process command line at 12:24). The other restored tabs got nothing.

At 14:02 I typed a message into one of the not-re-bound tabs (session 5fa29759-...):

• No Received message from webview: {"type":"io_message", ...} for it appears anywhere in the extension log (messages typed into healthy tabs are always logged there) — the send dies inside the webview.
• No process with --resume=5fa29759-... exists (Get-CimInstance Win32_Process filtered on claude.exe).
• The session .jsonl was never touched again (mtime frozen at the pre-restart time).
• The tab showed the spinner indefinitely; the stop/square button did nothing.

Steps to reproduce

1. Open several Claude Code chat tabs in VSCode with active/recently-active sessions.
2. Force an extension host restart (e.g. Developer: Restart Extension Host) — or have any misbehaving extension cause VSCode to restart it for you.
3. After the tabs are visually restored, type a message into a tab that was idle at restart time (not the most recently used one).
4. Observe: spinner forever, stop button non-functional, nothing appended to the session transcript, no error surfaced.

Expected behavior

Any of these would be fine:

• Restored tabs re-bind (or lazily respawn --resume=<session-id>) on the first message send, or
• The tab detects its channel is dead and shows "session disconnected — click to reconnect", or
• At minimum, the send fails loudly instead of dropping the message into a void with an infinite spinner.

Related (same routing/dispatch family, but different symptoms — none covers this)

• #77599 — subagent replies delivered to the wrong session (Windows, concurrent sessions)
• #76174 — run_in_background task-notification routed to a different session
• #69695 — extension tool dispatch never reaches the daemon (Windows)