VS Code extension: Open in editor respawns the CLI, killing a running background Workflow and leaving the UI stuck on "Vibing…" with a dead stop button

Environment

• Claude Code VS Code extension anthropic.claude-code-2.1.252-darwin-arm64, CLI 2.1.252 (bundled native binary)
• macOS 15 (Darwin 25.6.0), Apple Silicon
• Permission mode: bypassPermissions, model claude-opus-5

Summary

Reopening a running session in an editor tab (open_in_editor) tears down and respawns the CLI process for that session. Two things break as a result:

1. A background Workflow run launched by that session is killed mid-flight — it is owned by the old process and nothing survives the respawn.
2. The webview is then left permanently in the "Vibing…" running state with a non-functional stop button — the spinner belongs to a channel that has since been closed, so there is nothing left to interrupt.

The only way out I found was closing and re-creating the session tab.

Repro

1. In the VS Code extension, start a session and launch a long-running background Workflow (mine: 22 subagents, ~18 min in).
2. While it is running, click Open in editor to move the session into an editor tab.
3. Close that editor tab, and/or open the session in an editor again.
4. The session shows Vibing… forever. Clicking the stop (■) button does nothing. The composer shows "Queue another message…", so the UI still believes a turn is in flight.

Log evidence

Extension host log: ~/Library/Application Support/Code/logs/<window>/exthost/Anthropic.claude-code/Claude VSCode.log
Session id dfb51412-456f-4791-8e43-fcf642b57391, workflow run wf_d639df06-8fe, task id wmwbe3v1b.

14:21:52  Workflow launched in background (task wmwbe3v1b, run wf_d639df06-8fe)
14:22:04  update_session_state ... "state":"idle"        <- main turn finished, workflow still running

14:39:45.247  Received message from webview: {"type":"open_in_editor","sessionId":"dfb51412-..."}
14:39:45.652  Received message from webview: {"type":"launch_claude","channelId":"74wq3hj7u44",
              "resume":"dfb51412-...","freshStartIfUnresumable":false,...}
14:39:45.654  Spawning Claude with SDK query function - ... resume: dfb51412-...
14:39:47.181  <task-notification> status=stopped
              "No completion record was found for background workflow "explore-multi-address-order"
               from the previous session. It may have been stopped (via the UI or TaskStop ...),
               or it may have been running when the previous Claude Code process exited."

14:41:43.499  Closing Claude on channel: 74wq3hj7u44
14:57:46.123  launch_claude channelId "jj20ib1v8v" resume dfb51412-...   (open_in_editor again)
14:58:06.275  Closing Claude on channel: jj20ib1v8v
              -> from here the webview stays on "Vibing…" indefinitely

The workflow's own journal confirms it was killed mid-run, not finished:

$ python -c "count types in .../subagents/workflows/wf_d639df06-8fe/journal.jsonl"
Counter({'started': 22, 'result': 18})

4 subagents started and never produced a result; every agent-*.jsonl under the run dir stops writing at exactly 14:39, the second the respawn happened. The session transcript's last real entries are the stopped task notification plus a trailing last-prompt / mode record — the "Is the workflow stuck?" message I typed afterwards was never persisted at all.

Two things that look wrong beyond the teardown itself

• The notification says "from the previous session" even though the session id is unchanged (dfb51412-… resumed as dfb51412-…). It was the same session, a different process. That wording sent me looking for a session that did not exist.
• No interrupt/stop/cancel request of any kind appears in the extension host log — the only webview request types ever recorded are update_session_state, rename_tab, get_session_*, open_in_editor, launch_claude, etc. Prompt sends are not logged either, so this is not proof the click is dropped, but the session provably had no live channel behind it at that point.

Expected

• Moving a session into an editor tab should not kill the CLI process that owns its background work — or, if a respawn is unavoidable, background Workflow runs should survive it (or at minimum be re-attached / auto-resumed rather than silently orphaned 18 minutes and ~20 subagents in).
• Closing Claude on channel: X should reset the session's UI state to idle, so the spinner clears and the composer is usable.
• The stop button should be a no-op-safe escape hatch: if there is no live channel, clicking it should clear the stuck running state rather than doing nothing.