[BUG] Claude code vscode stuck cooking report

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment:

Claude Code CLI/extension version: cc_version=2.1.218.0f7 / 2.1.218.5bb (seen mid-session version bump)
Entrypoint: claude-vscode
Model: claude-sonnet-5

Problem:

The VS Code extension panel gets stuck showing the loading animation ("Cooking...", etc.) indefinitely after the actual task work has already finished. Console logs show that all tool calls (Read/Write/Edit/Bash/TodoWrite) completed successfully and the last API stream started and returned its first chunk normally. After that point, the log goes completely silent for ~48 seconds — no further tool dispatch, no LSP diagnostics polling, no hook checks, nothing.

When I manually sent an interrupt_claude message from the webview, the very next log line shows:

[DEBUG] "Hook Stop (Stop) cancelled:\nCompletion notification delivered for ClaudeCode.\n"

This indicates the backend had already generated and delivered a completion ("Stop") notification for the session, but the extension's webview never received/processed that event to transition the session state to idle. It only flipped to idle after I forced an interrupt.

What works:

All individual tool calls complete successfully (outcome=ok) with no errors.
API streaming works normally up to the last turn (Stream started - received first chunk).

What I tried:

Waited ~48 seconds with no change in UI state.
Manually triggered interrupt_claude from the webview, which immediately revealed the buried "Completion notification delivered" message and flipped session state to idle.

Expected: When the backend delivers a completion/Stop notification, the extension should transition the session UI state to idle automatically.

Actual: The completion event appears to be delivered/logged, but the extension UI keeps showing the loading animation until the user manually interrupts the session.

What Should Happen?

The extension should transition the session state to idle automatically once the backend's completion/Stop event fires, without requiring the user to manually interrupt the session.

Error Messages/Logs

Paths, filenames, and session/project titles below have been redacted/genericized.

[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 1495ms

--- (~48 seconds of complete silence: no tool_dispatch, no LSP diagnostics, no hooks check, no autocompact log — compare to the steady ~15s cadence of these logs throughout the rest of the session) ---

[info] Received message from webview: {"type":"interrupt_claude","channelId":"<redacted-channel-id>"}
[info] Interrupted Claude for requestId: <redacted-request-id>
[DEBUG] "Hook Stop (Stop) cancelled:\nCompletion notification delivered for ClaudeCode.\n"
[DEBUG] Fast mode unavailable: Fast mode requires usage credits · /usage-credits to turn them on
[info] Received message from webview: {"type":"request","requestId":"<redacted-request-id>","request":{"type":"update_session_state","sessionId":"<redacted-session-id>","state":"idle","title":"<redacted-title>"}}

For context, here is a representative slice of the normal, healthy pattern that repeats throughout the rest of the session (tool dispatch → LSP check → hooks check → autocompact → next API request), included to show what "working" looks like versus the silent gap above:

[INFO] [Stall] tool_dispatch_start tool=Edit toolUseId=<redacted> permissionDecisionMs=2
[DEBUG] FileHistory: Tracked file modification for <redacted-path>
[DEBUG] Writing to temp file: <redacted-path>.tmp.<redacted>
[DEBUG] Temp file written successfully, size: <redacted> bytes
[DEBUG] Renaming <redacted-path>.tmp.<redacted> to <redacted-path>
[DEBUG] File <redacted-path> written atomically
[INFO] [Stall] tool_dispatch_end tool=Edit toolUseId=<redacted> outcome=ok durationMs=8

[info] [DiagnosticTracking] No new diagnostics found for <redacted-path>
[DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
[DEBUG] LSP Diagnostics: Checking registry - 0 pending
[DEBUG] Hooks: Found 0 total hooks in registry
[DEBUG] Hooks: checkForNewResponses returning 0 responses
[DEBUG] autocompact: tokens=[REDACTED] level=ok effectiveWindow=947000
[DEBUG] Dynamic tool loading: found 1 discovered tools in message history
[DEBUG] Dynamic tool loading: 1/18 deferred tools included
[DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.218.0f7; cc_entrypoint=claude-vscode; cch=00000; cc_prev_req=<redacted>;
[DEBUG] Fast mode unavailable: Fast mode requires usage credits · /usage-credits to turn them on
[DEBUG] [API:timing] dispatching to firstParty model=claude-sonnet-5
[DEBUG] [API REQUEST] /v1/messages x-client-request-id=<redacted> source=sdk

[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 1650ms

Notice how every turn in the working pattern immediately triggers the LSP/Hooks/autocompact/dispatch sequence within milliseconds of the stream's first chunk. In the failure case, that sequence simply never fires after the final Stream started - received first chunk — the extension appears to be waiting on an event that was already emitted and logged (Completion notification delivered for ClaudeCode) but not delivered to the UI layer until a manual interrupt forced a state refresh.

Steps to Reproduce

Run a longer multi-step task in the VS Code extension (multiple Read/Write/Edit/Bash/TodoWrite tool calls across several turns).
Let the task run to completion.
Observe that after the final tool call and final API stream's first chunk, the UI continues showing the loading animation with no further activity in the logs.
Manually send an interrupt (stop button) — note that the log immediately shows a "Hook Stop (Stop) cancelled: Completion notification delivered for ClaudeCode" message right after the interrupt is processed, suggesting the completion signal existed but wasn't consumed by the UI.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code CLI/extension version: cc_version=2.1.218.0f7 / 2.1.218.5bb

Platform

Other

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

This looks related to #17926 ("VS Code extension not responding - stuck on Forging/Cooking/Pondering...") but with more specific evidence: in that report the extension never responds at all, whereas here the backend clearly completes the task and logs a completion/Stop notification — the failure is specifically in the UI/webview not consuming that event and updating session state to idle.