VS Code extension: orphaned chat webview after extension host restart silently swallows submitted prompt — fake 'thinking' state, dead stop button, message never persisted

Environment

• Claude Code v2.1.214, VS Code extension (entrypoint: claude-vscode)
• macOS (Darwin 25.4.0)
• Long-running session with a ~454 MB transcript JSONL

Correction from the original report: the prompt was NOT lost from the input box. It was submitted. The UI accepted it, displayed it in the conversation, and showed Claude thinking. It never replied. The stop button was clicked 5 times with no effect. The user closed the chat panel (VS Code itself stayed open) and reselected the chat — the submitted message was gone, unrecoverable.

Log-verified timeline (extension host log + exthost.log, all local time)

• 09:59:17 — while the user composed a long prompt, the webview logged input_lag_sample durationMs: 256 (the extension's own instrumentation caught the input path lagging).
• 10:03:59.250 — Extension host terminating: renderer closed the MessagePort. Old exthost (pid 43672) exits; new host (pid 95278) starts; the Claude extension re-activates at 10:04:00 and again 10:04:12 (two activations, two MCP ports). The user closed nothing — this happened underneath an open chat panel.
• 10:04:12 → 10:37:05 — zero log entries. In this window the user finished composing, hit submit, watched the message render + a thinking spinner, and clicked stop 5×. None of these events were ever received by the extension host: no "Received message from webview", no "Spawning Claude", nothing. The webview panel survived the host restart in the renderer but its message channel was never re-established — it rendered a fully fake in-progress state while talking into a void.
• 10:37:05 — panel reopened: fresh webview (new channelId), session resumed from the on-disk JSONL — whose last user message is from the previous day. The submitted prompt never existed anywhere durable.
• 10:37:15 — post-reopen input_lag_sample durationMs: 856.

Why this is severe
The UI affirmatively told the user their message was submitted and being processed. Both were false. There is no ack path: a message is rendered as "sent" without the host confirming receipt or persistence, so a webview orphaned by a host restart silently destroys user work while displaying success.

Asks

1. Ack-gated submit: render a message as sent only after the extension host confirms it was appended to the session JSONL; on no-ack, keep the text (restore to the input box) and surface an explicit error.
2. Persist at submit: append the user message to the transcript before/independently of inference, so any downstream failure leaves it on disk.
3. Detect orphaning: heartbeat between webview and host; on host restart, the panel should show "reconnecting/disconnected", not accept input into the void.
4. Stop must fail loudly: if the interrupt can't reach a live backend, say so instead of no-opping.
5. Recover on reopen: restore any unacknowledged submitted message after an unclean disconnect.
6. Perf: the input-lag telemetry (256→856 ms) alongside a ~454 MB session transcript suggests very large long-running sessions degrade the input path and may be implicated in the renderer-initiated host restart — worth investigating as the trigger.

🤖 Filed with Claude Code on the user's behalf; timeline reconstructed from ~/Library/Application Support/Code/logs/ exthost logs and ~/.claude/ session state.