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

Hitting the same "Secondary Issue: Silent Rate Limit Failures" pattern described above, with one additional data point that might help narrow down the root cause: the classifier's own system prompt appears to be the thing burning the rate-limit budget, not the main loop.

Environment

• Claude Code (VS Code extension), reproduced on both v2.1.152 and v2.1.227 (upgraded mid-investigation, issue persisted identically — not fixed by updating)
• Linux
• Permission mode: auto
• Subscription: Claude Max, at the time of the errors: 41% of 5-hour session limit, 8% of weekly limit used — nowhere near the account's usage cap, which rules out a simple "you're out of quota" explanation.

Evidence: classifier prompt size vs. main request

Claude Code dumps the failing classifier request to /tmp/claude-*/auto-mode-classifier-errors/<sessionId>.txt on error. For a single trivial action ({"Bash":"cd ~/workspace/<project> && ls -la"}), the dump showed:

model: claude-sonnet-5
mainLoopTokens: 14480
classifierChars: 112569
classifierTokensEst: 28142
delta (classifierEst - mainLoop): 13662

The classifier's own request (~28k tokens, system prompt alone is ~112k chars — a "security monitor for autonomous AI coding agents" prompt) is almost twice the size of the main-loop request it's evaluating. In an auto-mode session with many quick sequential tool calls (in my case amplified by a PreToolUse hook that intercepts every Bash invocation individually), this multiplies token throughput fast enough to trip a short-term rate limit even though overall plan usage is low.

Logs (matches the pattern already reported above)

[WARN] [Stall] classifier_request_finished reqId=... tool=Bash stage=xml_s1 outcome=error durationMs=8000-10000 errorKind=Error:429 {"type":"error","error":{"type":"rate_limit_error","message":"Error"}}
[WARN] Auto mode classifier (XML) error: 429 {...}
[DEBUG] Auto mode classifier: Sonnet 5 probe demotion errorKind=http_429

Sample request_ids for backend correlation (repeated ~every 8-30s over multiple 5-10 minute windows, both before and after the version upgrade):

• req_011CdvjCxJPVuxcSTfyj5R21 (2026-08-11T09:31:28.414Z, v2.1.227)
• req_011CdvjCAu8udXCvDzXoFLFK (2026-08-11T09:31:17.770Z, v2.1.227)
• req_011CdvhSEEy1girrtvGf5LHX (2026-08-11T09:08:14.812Z, v2.1.152)
• req_011CdvhRySE8JvWajjmEuYws (2026-08-11T09:08:11.485Z, v2.1.152)
• Same pattern also seen on 2026-08-07 (~14:11 UTC), 6 occurrences in that window alone — this is recurring, not a one-off.

Checked status.claude.com at the time: no ongoing incident reported.

Suggested fix direction

Given the classifier prompt is bigger than the request it's classifying, trimming what gets sent to the classifier (e.g. not re-sending full transcript/tool schemas on every single tool call, or caching the static parts) seems like it would both reduce latency (the 8-10s stalls) and make auto mode much less likely to trip short-term rate limits during normal fast-paced sessions — independent of fixing the retry/timeout behavior already requested above.

Happy to share the full dumped classifier-error file (redacted) if useful.

Hello — same webview channel error signature, different repro path, cross-linking for visibility.

We hit this exact log line too, but the trigger was different: a third-party
Anthropic-compatible provider emitting one SSE content_block_delta event
per token (thinking-heavy turns → ~6300 events per response). The extension
fell behind the stream (per-event render over Remote-SSH), the CLI blocked
on stdout backpressure, and permission/plan prompts were displayed
minutes-to-hours late — while our Notification hook fired on time, proving
the CLI had already processed the response.

Key data from the affected session:

6400 output tokens → 6314 SSE delta events (~135B each); the official API
batches multiple tokens per delta — 1–2 orders of magnitude fewer events.
Combination matrix: terminal + provider fine, extension + official fine,
extension + provider stalls — only the event granularity varies.
A proxy-level SSE coalescing workaround (merge consecutive same-type
deltas into time-windowed batches) cut the event rate ~3–23x; the prompt
delay went tens of minutes → ~3 min → seconds, with no other variable
changed.
Full writeup with the evidence: #86854.

Both cases point at the same CLI↔webview channel dropping/silencing
responses under stress — in yours the decision never dispatched with no
timeout; in ours responses arrived after the CLI had already dropped the
request. Worth fixing together: batch stream-event rendering on the webview
side, and stop silencing channel errors.

Still reproduces on 2.1.259 (VS Code extension native binary, macOS 26 / Darwin 25.6.0, Apple Silicon), permission mode auto, with the sessions driven from another device via Remote Control. Two independent sessions on the same machine hung this way on the same day (11:22 and 16:53 local), while three sibling sessions under the same extension host kept working. Adding the process-level evidence since the earlier reports are mostly log-based.

Fingerprint (same as above)

• Last transcript line is an assistant Bash tool_use; no tool_result, and none of the internal atis-latch / frame-link / bridge-session entries that appear between tool_use and result in every healthy round of the same transcripts.
• No child process was ever spawned: the command never started, and no hook was running (one PreToolUse and one UserPromptSubmit hook are configured; neither was alive).
• Process state S, 0.0% CPU, hours at a time. Not spinning.
• Machine never slept: pmset -g shows sleep 0, uptime 17 days, no sleep/wake entries in pmset -g log around either hang.

What's different from a plain idle event loop: leaked half-closed sockets

lsof -i on the two hung processes vs. the healthy ones at the same moment:

| session | API connections | Remote Control relay connection |
|---|---|---|
| hung A (stuck ~6 h) | CLOSED | CLOSED |
| hung B (stuck ~40 min) | 3× CLOSE_WAIT, 1× CLOSED, 1× ESTABLISHED | CLOSED |
| 3 healthy siblings | all ESTABLISHED | ESTABLISHED |

CLOSE_WAIT means the far end closed the connection and the client never closed its side, i.e. a request whose connection was dropped without the client noticing or timing out. That matches the "classifier/permission path with no timeout" theory in this issue and the dropped-continuation shape in #94252 and #95354.

Other observations

• The cross-session messaging socket (/tmp/cc-socks/<pid>.sock) refused messages from a peer session, consistent with the process being stuck inside a tool round.
• SIGTERM was ignored; SIGKILL was needed.
• Recovery: claude --resume <id> --remote-control <name> --permission-mode auto from a terminal on the machine picks the transcript up and re-issues the stalled call. Nothing can be done from the remote device, which is what makes this painful when the person is away from the machine.

Happy to share transcript tails privately (they contain project paths).