VS Code extension: same conversation opened in two editor panels — sending from one panel hangs forever on 'Processing…' (turn is black-holed)

Summary

When the same Claude Code conversation is opened in two side-by-side VS Code editor panels in the same window (e.g. duplicated via the history dropdown into a split editor group), sending a new message from one of the panels never receives a response. The sending panel shows Processing… indefinitely. The other panel does not show the new user message or any response either. The turn is effectively black-holed.

Environment

• Extension: anthropic.claude-code-2.1.141-win32-x64 (also 2.1.140 present from prior auto-update)
• VS Code: latest
• OS: Windows 11 Pro 10.0.26200
• Workspace: VS Code multi-root workspace (4 sub-folder repos)

Steps to reproduce

1. Open a Claude Code conversation in editor panel A (from the history dropdown).
2. Split the editor group and open the same conversation in panel B (also from the history dropdown).
3. In panel A, type a new prompt and submit it.

Expected

Either:

• Both panels mirror the new turn and stream the response in lockstep, or
• Only one panel is allowed to own the live session and the other shows a read-only / "view-only" notice with a button to take ownership.

Actual

• Panel A (sender): spinner stays on Processing… forever. Input box stays in the Queue another message… (busy) state. No response ever renders. Cancelling / Ctrl-Esc does not recover the panel cleanly.
• Panel B (the other view of the same session): does not show the new user message at all — it still displays the previous turn (Want me to poll the CI status? in my repro). No assistant response appears here either. Input box sits in the idle ctrl esc to focus or unfocus Claude state.
• The agent appears to have no UI surface to deliver the streamed response into, so the turn is silently dropped.

Impact

• Lost prompt / lost turn cost (model still ran on the server side AFAICT — usage was debited).
• No UI affordance warns the user that duplicating a session into a second panel will break it. Opening a session in two panels is a natural workflow for cross-referencing earlier output while typing a follow-up.
• Recovery requires closing one panel and frequently reloading the VS Code window before the session is usable again.

Suggested root cause

Webview ↔ agent IPC ownership likely binds the streaming output channel to a single panel instance. When the same conversation is opened in a second panel:

• Either the second open silently detaches the stream from the first panel (so A's UI never receives stream events / terminators after submitting), or
• The new subscription is refused silently and the submit-side writer in A has no listener on the other end.

Either way, A's Processing… is a UI state waiting for stream events that will never arrive, and B isn't subscribed to A's submit either.

Suggested fix

Detect duplicate session subscriptions in the same VS Code window and pick one of:

1. Reject + focus: when a session is opened a second time, reveal the existing panel instead of creating a duplicate webview.
2. Multicast: allow N read-only mirror panels, and broadcast stream events to all of them. Promote one panel as the writer; the others get a "view-only — switch focus to write" affordance.
3. At minimum surface a banner in the second panel: "This conversation is already open in another panel — close that one to interact here."

Notes

• I'll attach a screenshot showing the two side-by-side panels (left: Processing… forever after a new prompt about PR #2675; right: same titled session showing only the previous turn) in a follow-up comment.
• Happy to grab logs from ~/.claude/ or run /doctor output if a maintainer points me at what's most useful.

<img width="1906" height="1000" alt="Image" src="https://github.com/user-attachments/assets/d22026bc-b500-4a44-be6b-cc6c333d92d6" />