[BUG] [VS Code] Moving the Claude Code view to another container (Move to Panel / Side Bar) kills the running session mid-turn; each move spawns and kills a resume

Environment

• Claude Code VS Code extension 2.1.280 (win32-x64, bundled native-binary/claude.exe)
• VS Code on Windows 11 Pro 10.0.26200, 16 GB RAM (heavily loaded: ~0.9 GB free, commit 28.9/42.9 GB)
• Two Claude Code sessions open in the same window. One of them was mid-turn, running a long Bash tool (mvn test, ~2 min).

Summary

Moving the Claude Code view to another view container (right-click the view title → Move to → Primary Side Bar / Panel / Secondary Side Bar) disposes and re-resolves the WebviewView. The extension then kills the CLI subprocess of the running session, mid-turn and mid-tool.

Each later move spawns a resume with resumeInterruptedTurn: true, and the next move kills it again. In my case the last resume then hit the fixed 60 s init limit ("Subprocess initialization did not complete within 60000ms — check authentication and network connectivity", see #90656 / #93795). The panel was left without the conversation and without a retry option. I had to find the session in the history list.

This looks like the same root cause as #91206 (Open in editor respawns the CLI), reached through a different trigger: moving the view between containers.

Steps to reproduce

1. Put the Claude Code view in the Secondary Side Bar. Start a turn that runs a long tool call (e.g. a Bash command lasting 1–2 min).
2. While the tool is running, right-click the view title → Move to → Primary Side Bar.
3. Then Move to → Panel.
4. Then Move to → Secondary Side Bar.

All three moves happened within about 40 s. I've hit this twice.

Expected

Moving the view is a UI-only change. The running turn and its tool call keep going, and the new webview re-attaches to the existing channel.

Actual

The session's process is closed on the first move, and the in-flight tool call is lost. The session JSONL ends with an assistant tool_use that has no tool_result.

Evidence

From the extension log Claude VSCode.log. Times are local (UTC+2); the lines marked [CLI] come from the subprocess's stderr.

15:42:16.844 Closing Claude on channel: b68xkk2ojr            <- move #1; session mid-turn (Bash tool running)
15:42:18.136 webview request {"type":"init"}                  <- new webview
15:42:22.032 launch_claude {resume:"3d393d65…", resumeInterruptedTurn:true} channel vgx73zglv3
15:42:24.107 Spawning Claude … resume: 3d393d65…
15:42:27.876 Closing Claude on channel: vgx73zglv3            <- move #2, 3.8 s after spawn
15:42:43.883 [error] Failed to load config cache: Error: Host shutting down
15:42:47.729 launch_claude {resume:"3d393d65…", resumeInterruptedTurn:true} channel tkgf73rqde
15:42:50.959 [CLI] Auto-resuming interrupted turn (kind: interrupted_prompt)
15:42:56.750 Closing Claude on channel: tkgf73rqde            <- move #3
15:43:02     the "closed" process still appends a new assistant tool_use (Bash) to the session JSONL
15:43:38.435 launch_claude {resume:"3d393d65…", resumeInterruptedTurn:true} channel qua9zlq6gh
15:43:47.211 Spawning Claude … resume: 3d393d65…              <- 8.8 s host pre-spawn (pythonEnvMs)
15:43:52.141 launch_claude (no resume) channel 066839rwpkwf   <- same webview also opens a fresh session
15:44:46.111 [CLI] FileHistory: … resuming with same session id: 3d393d65…
15:44:47.010 [error] Error spawning Claude (on channel qua9zlq6gh): Subprocess initialization did not complete within 60000ms …
15:44:49.472 [CLI] Auto-resuming interrupted turn             <- the CLI was alive, 2.5 s from ready

Other observations:

• Transcript write race. The process closed at 15:42:56.750 was still writing to the session transcript 6 s later, while the next process was being launched to resume the same session.
• The resumed turn was killed too. The auto-resumed turn had already been re-issued, with a new tool call, before being killed. On a slower tool it would have been killed mid-execution a second time.
• Auth and network were fine throughout. The log shows OAuth tokens found in secure storage every time, and the other session in the window kept streaming normally.
• The final timeout came from load. Fresh CLIs logged [event-loop-stall] blocked for 2298…4896ms with majflt up to 12,619. In addition, claudeCode.usePythonEnvironment (default true, in a Java workspace) cost 9.7–25.5 s of hostPreSpawnMs per launch in this window.

Suggested fixes

1. Decouple the CLI process lifetime from the WebviewView. When the view is disposed because it moved, keep the channel alive and re-attach it when the view is resolved again, rather than closing it and resuming. retainContextWhenHidden: true covers hide/show, but not moves between containers.
2. Debounce re-resolves. If a relaunch is still needed, debounce it, and wait for the previous process to exit before resuming the same session. That would avoid the double writer on the JSONL.
3. After a failed resume, show a Retry action that resumes the same session, instead of an empty panel. The timeout itself is covered by #90656 / #93795.

Workarounds

• Only move the view while the session is idle, and in a single step (Secondary Side Bar → Panel directly).
• Recover with the session list → pick the session. The transcript is intact up to the interrupted tool call.