[BUG] VS Code extension: live session UI stuck on "Combobulating…" after background workflow completes (result is saved but only appears after reopening/reloading the session)

Summary

When a background Dynamic Workflow (Workflow tool, run_in_background) is started in the Claude Code VS Code extension, the originating live session stays on a perpetual working spinner ("Combobulating…") and never renders the completed result — even after waiting ~1 hour. Sending a follow-up message ("what's the progress?") in that same session produces no visible response either; the panel appears frozen.

However, the workflow actually completed successfully: the task-notification fired, the output file was read, and the full answer was produced and persisted to session state. This is verifiable by opening the same session from chat history in a different/new VS Code window (or running "Developer: Reload Window") — the completed result is already there.

In other words, the result is not lost and the completion notification is not missing. The defect appears to be that the live VS Code extension webview/panel in the originating session fails to re-render the completed turn until the session is reloaded. This looks like a webview UI state-sync/refresh bug in the extension, not a backend/notification-delivery problem.

Environment

• OS: macOS (Darwin 24.6.0), Apple Silicon (MacBook Air M1)
• VS Code extension: anthropic.claude-code 2.1.191 (darwin-arm64) — latest at time of report
• Claude Code CLI (at the time the bug occurred): 2.1.128, native install at ~/.local/bin/claude (PATH resolved to this one)
• Other installs present at the time: an npm-global copy (~/.npm-global, 2.1.128) and a system-wide npm copy (/usr/local/bin/claude). Three claude installs were present simultaneously; PATH resolved to the native one. The CLI has since been updated to native 2.1.191 and the npm-global duplicate removed, but the bug was observed with the live setup: extension 2.1.191 + native CLI 2.1.128, three installs present.
• Feature in use: Dynamic Workflows (the Workflow tool, run_in_background) and background research/agents

Steps to reproduce

1. In the VS Code Claude Code extension, start a background workflow or background research (Workflow tool / run_in_background).
2. Wait for it to finish.
3. Observe the live session: it stays on the working spinner ("Combobulating…") and never shows the result. A follow-up message in the same session also produces no visible response.
4. Open the same session from chat history in a new VS Code window (or run "Developer: Reload Window"). → The completed result is already there.

Expected

When the background workflow completes and its result is persisted to session state, the live VS Code extension panel for the originating session should automatically re-render the completed turn (replace the spinner with the final answer) without requiring a manual reload.

Actual

• The live session shows a perpetual "Combobulating…" spinner and never renders the completed turn, even after ~1 hour.
• Follow-up messages in the same live session produce no visible response; the panel appears frozen.
• Reopening the same session from chat history in a new window — or reloading the window — reveals the already-completed result, confirming the result was correctly produced, the notification fired, the output file was read, and everything was saved to session state.

Why this is distinct from related issues

The decisive distinguishing facts here are: the task-notification DID fire, the output file WAS read, the full answer WAS produced, and it WAS persisted to session state. The only failure is that the live VS Code extension webview does not re-render the completed turn until reload. That places this report at a different layer (extension rendering) and a different failure mode (render-not-refreshed vs. delivery-lost) from the following:

• #66311 (closest) — Reported as a backend/harness delivery bug: a run_in_background Bash loop completes but the <task-notification> is never fired and the output file stays 0 bytes, so the result is effectively lost. That is the opposite of this report at the data layer (here the notification fired and the result was saved). Also a different environment (CLI background Bash on Linux vs. VS Code extension + Dynamic Workflows on macOS). Shared only at the surface ("completed background task not surfacing in the live UI").
• #68749 — Reported as an engine-level defect where a fork/subagent's wake subscription is torn down, so the last pending background task's completion notification is never delivered and produces no output (data never reaches the session). Here, by contrast, the data DID reach session state. Scoped to Linux fork/subagent, with no webview dimension.
• #68997 — Reported as a notification-dispatch bug in multi-agent orchestration: notifications are silently dropped / ghost-refired / misrouted, so the completion signal is lost. Here the signal was not lost. Different context (sequential multi-agent Agent() dispatch on CLI 2.1.179) vs. a single background Workflow run in the extension.
• #68922 — Reported as a model-reasoning/agent-lifecycle bug where the model asserts completion before the authoritative <task-notification> arrives (result not yet produced). Here it is the inverse: the result was correctly completed and persisted, but the webview does not repaint.
• #70726 — Windows / Anthropic API, area:agent-view (FleetView/agent-view panel): background tasks show "Running" for 129–143 hours with quota/lockout concerns — a persistent backend "Running" status. Here the backend state is correct and the result is saved; only the live VS Code webview fails to repaint until reload. Different OS, different client surface, different layer.

In short, per the principle that "notification never fires / result lost" is a different defect from "result persisted but UI not refreshed," this is not a duplicate of any of the above. It appears to be a VS Code extension webview UI state-sync/refresh bug.

Workaround

Open the same session from chat history in a new VS Code window, or run "Developer: Reload Window". The completed result then appears.

Secondary note (minor, likely unrelated)

In the 2.1.191 extension build, typing /workflows in the input box shows "No matching commands" — the slash command does not autocomplete in this build, so I could not use /workflows to inspect the run. Mentioning this only as a possibly-related secondary observation; it is clearly separate from the main UI-refresh bug above.