VS Code/Cursor extension: session hangs forever after auto-mode classifier_request_finished (no timeout, webview channel errors silenced)

Summary

In the VS Code / Cursor extension, sessions freeze mid-run several times per session (4-6x). The hang happens in the auto-mode permission path: the permission classifier request completes successfully, but the decision never reaches dispatch — no tool_dispatch_start, no permission prompt, no error, and no timeout, so the session waits forever. The UI shows nothing; the only recovery is closing and reopening the chat (which rebuilds the webview channel) and sending a new message. Because the stall usually outlives the prompt-cache TTL, each recovery re-sends the full context uncached (~14% of a session's usage burned per stall).

Environment

• Extension: Claude Code for VS Code, cc_version=2.1.220.26d, cc_entrypoint=claude-vscode
• IDE: Cursor on macOS (Darwin 25.5.0)
• Permission mode: auto (Bash commands routed through the claude-sonnet-5[1m] classifier, stage=xml_s1)
• Plan: paid subscription

Evidence from Claude VSCode.log

Healthy flow (2026-07-26 17:08:29 UTC) — classifier finishes, decision lands, tool dispatches:

17:08:25.993 [INFO] [Stall] classifier_request_started reqId=37a6e8cd-... tool=Bash model=claude-sonnet-5[1m] stage=xml_s1
17:08:29.564 [INFO] [Stall] classifier_request_finished reqId=37a6e8cd-... outcome=ok durationMs=3571
17:08:29.581 [INFO] Slow permission decision: 3645ms for Bash (mode=auto, behavior=allow)
17:08:29.591 [INFO] [Stall] tool_dispatch_start tool=Bash toolUseId=toolu_01BQWDA1PsLZBiXdYSL2YRtr permissionDecisionMs=3645

Hang, 3 minutes later (2026-07-26 17:11 UTC) — same session, classifier finishes, then nothing, forever:

17:11:25.885 [INFO] [Stall] classifier_request_started reqId=1f0bae18-4ea6-47d5-a9f5-d2f0980acf8c tool=Bash model=claude-sonnet-5[1m] stage=xml_s1
17:11:25.955 [DEBUG] [API REQUEST] /v1/messages x-client-request-id=23678dae-fd3f-4140-beb1-28d7558d1888 source=side_query
17:11:28.436 [INFO] [Stall] classifier_request_finished reqId=1f0bae18-4ea6-47d5-a9f5-d2f0980acf8c tool=Bash stage=xml_s1 outcome=ok durationMs=2551
   <-- nothing after this: no permission decision, no tool_dispatch_start, no error, no timeout -->
17:14:58.521 [DEBUG] Invalidating session environment cache   <-- user closed/reopened the chat to recover

The command being classified was npx vitest ... (an allow-suggestion for it was logged at 17:11:25.829).

Likely related — every session start logs a webview channel error and then goes silent about further drops, which would explain why the hangs leave no error trace:

[WARN] claude-vscode notification channel error: Received a response for an unknown message ID: {"jsonrpc":"2.0","result":{},"id":0}; further channel errors are not logged this session

A second symptom of the same channel flakiness observed the same evening (17:28:16 UTC): the webview flipped the session to state:"idle" while a subagent (source=agent:builtin:general-purpose) was still actively streaming API requests.

Separate but related: silent give-up on 429

Two other freezes were a different failure: on an account rate limit the extension logs API error (attempt 1/11): 429 rate_limit_error but gives up immediately after attempt 1 (API rate_limit after retries) and flips the session to idle with no visible error. Request IDs for server-side lookup:

• req_011CdPNNLX3yrcUAWzXCkjYN (2026-07-25 19:59 UTC+2)
• req_011CdQt9Dup3M2oLnovPihZ1 (2026-07-26 15:10 UTC)
• x-client-request-id 4be74d05-690b-46c0-b5e1-d5a84c4b05bf

Expected behavior

1. A timeout + retry (or a surfaced error) on the permission-decision path so a dropped channel message cannot hang the session forever.
2. Channel errors should keep being logged (or re-establish the channel) instead of "further channel errors are not logged this session".
3. A 429 with retry budget "1/11" should actually retry with backoff, or clearly tell the user why it stopped.

Impact

4-6 hard freezes per working session; each recovery requires closing/reopening the chat and re-sending context uncached, burning a significant share of the session's usage quota.