[BUG] Response stream stalls after first byte with no timeout/recovery — indefinite livelock in Auto mode

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
OS: Windows (Dell laptop)
Extension: Claude Code for VS Code
Extension/CLI version: cc_version=2.1.220 (seen as both 2.1.220.3fc and 2.1.220.98d in the same session)
Model: claude-sonnet-5
Permission mode: auto (organization has Fast mode disabled: Fast mode unavailable: Fast mode has been disabled by your organization)
Entrypoint: claude-vscode
What's wrong

Correction from initial report: this was first reported as an API stream that stalls after the first byte with no recovery. After reopening VS Code and resuming the affected session (resume: <session-id>), it became clear the underlying session had actually continued running and produced further output in the background past the point where the Output panel/webview appeared frozen — all the way up to when the user manually interrupted to refresh. So the process was not actually hung; the Output panel and/or the chat webview simply stopped reflecting the session's real progress, while work continued underneath.

This is therefore a UI/logging display desync, not a network/API livelock: the visible symptom (no new output, everything appears frozen, CPU still active) is real, but the backend session state is not actually stuck.

Request
What could cause the Output panel logging and/or the chat webview to stop reflecting session progress while the underlying SDK session keeps running? Is this a webview IPC message queue issue, an Output channel buffering/flush issue, or something else?
Could a lightweight heartbeat/liveness indicator be added to the UI so users can distinguish "still working, display desynced" from "actually stuck" without needing to force-restart?
Given the classifier side-query's classifierChars grows monotonically within a session (observed increasing across at least 3 consecutive tool calls just before this incident), is there a chance that growing message-passing volume between extension host and webview contributes to the desync over long sessions?

This may or may not share a root cause with a separately filed report about settings.local.json watcher cascades causing livelocks across multiple tabs on the same project — filing separately since the failure signature here (stream stall, no watcher/lock activity in the surrounding log) looks mechanically distinct.

What Should Happen?

If the Output panel/webview loses sync with the actual session state, it should either recover automatically (re-render from current state once the desync is detected) or at least surface a visible indicator ("reconnecting", "display out of sync") rather than silently showing a frozen, unchanging view that looks indistinguishable from an actual hang. Users currently have no way to tell "this is genuinely stuck" apart from "this is still working, the display just isn't showing it" — the only way to find out is to force-close and reopen/resume the session, which is a poor diagnostic experience and leads users (including us) to force-restart sessions that were actually fine.

Error Messages/Logs

Last lines captured in the Output panel at the moment the UI appeared frozen (nothing further appeared in the panel from this point, despite the session continuing to work in the background — confirmed by reopening/resuming the same session afterward and finding further progress had occurred):

2026-08-01 11:24:21.791 [info] From claude: 2026-08-01T09:24:21.791Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=13c796f2-4230-4c90-8b8f-b565ab58e4e2 source=sdk

2026-08-01 11:24:24.022 [info] From claude: 2026-08-01T09:24:24.023Z [DEBUG] Stream started - received first chunk
2026-08-01T09:24:24.023Z [DEBUG] [API:timing] first byte after 2241ms

→ End of visible log at the time. No further entries appeared in the Output panel (no tool_dispatch_start, no error, no stream completion, no reconnect attempt) even though the session was, per the follow-up observation above, still actually progressing.

Preceding warning signs (same session, shortly before the freeze)

Several Bash tool dispatches ended in error with unusually long durations right before the final hang, suggesting degraded conditions leading up to it:

2026-08-01T09:02:58.226Z [WARN] [Stall] tool_dispatch_end tool=Bash toolUseId=toolu_01AN1yMmieNoEgtLmuBrgqQx outcome=error durationMs=4066
2026-08-01T09:18:39.200Z [WARN] [Stall] tool_dispatch_end tool=Bash toolUseId=toolu_01MQbTpAV2ajT1FRfgYZNfy6 outcome=error durationMs=8057
2026-08-01T09:23:47.871Z [WARN] [Stall] tool_dispatch_end tool=Bash toolUseId=toolu_014EDyTiUv6Ycoz7RapGQSaj outcome=error durationMs=2552
2026-08-01T09:23:47.871Z [DEBUG] Bash tool error (2552ms): Shell command failed

Also present throughout: a config lock failure at session start (separate from the freeze itself, but indicating lock contention was already a factor in this session):

2026-08-01T08:39:47.414Z [ERROR] Failed to save config with lock: Error: Lock file is already being held
Auto-mode specific overhead observed

Each Bash tool call in Auto mode triggers a separate classifier side-query (source=side_query) to decide the permission behavior, adding measurable latency and a steadily growing context on every iteration:

[auto-mode] context comparison: ... classifierChars=182524 ...
[auto-mode] context comparison: ... classifierChars=182832 ...
[auto-mode] context comparison: ... classifierChars=183293 ...
2026-08-01T09:23:53.611Z [INFO] Slow permission decision: 2150ms for Bash (mode=auto, behavior=allow)

classifierChars grows monotonically across the session (visible over at least 3 consecutive tool calls), and each classifier round-trip added 1.6–2.1s of latency on top of the normal tool dispatch. Not confirmed as the direct cause of the stream stall, but flagged since it correlates with the failure window and adds request volume/latency that could plausibly contribute to hitting a stream/network edge case.

Steps to Reproduce

Occurred during a long-running Auto-mode session performing repeated Bash tool calls (Python scripts inspecting JSON scratch files under a per-session temp scratchpad directory). No special action was needed to trigger it — it happened during otherwise normal iterative data-inspection work.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Related issue

This was initially misdiagnosed by us as an API stream stall (see revision note above) before we discovered, by resuming the session, that work had actually continued. It may or may not share a root cause with a separately filed report about settings.local.json watcher cascades causing genuine livelocks (CPU-active, no progress at all) across multiple tabs on the same project — filing separately since that one is a confirmed real livelock, while this one is a display/sync issue with no actual stall.