[BUG] VS Code extension (Remote-SSH): per-event stream rendering delays permission prompts by minutes-to-hours with fine-grained SSE providers

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?

The Claude Code VS Code extension (over Remote-SSH) falls minutes-to-hours
behind the model stream when the endpoint is an Anthropic-compatible provider
that emits one SSE content_block_delta event per token. The CLI receives and
processes the complete response within seconds (a Notification-type hook fires
on time), yet the extension keeps showing "working" and permission
requests / AskUserQuestion prompts are displayed extremely late. The same
provider works fine in the terminal, and the extension works fine against the
official API — the failure occurs only when the extension meets a fine-grained
event stream.

What Should Happen?

• Permission prompts / plan approvals / AskUserQuestion should be displayed

promptly after the CLI receives them, regardless of stream event granularity.

• The extension's render cost should not scale linearly with the number of

stream events.

• Control messages should never queue behind content rendering.

Error Messages/Logs

Extension host log signature (seen at the start of affected sessions):


claude-vscode notification channel error: Received a response for an unknown message ID: ... id:0


Observations consistent with the failure:

- CLI process alive in S state, **zero TCP connections, zero child processes** —
  not waiting on the network; blocked writing to its own stdout (extension host
  not draining fast enough; 64KB pipe backpressure).
- Session transcript shows the complete assistant response (`stop_reason:
  "tool_use"`, full usage) and a Notification hook fired on time — the CLI had
  already finished the turn — but no terminal `result` event: the turn never
  completed CLI-side.

Steps to Reproduce

Setup:

• VS Code Remote-SSH to a Linux host with the Claude Code extension.
• Point the extension at a third-party Anthropic-compatible endpoint that emits

per-token deltas (we use Zhipu GLM coding plan, anthropic_messages-style
streaming, thinking enabled) via a local gateway.

• Use a long conversation with many prior turns.

Steps:

1. Run a long, thinking-heavy agentic turn (e.g., a large file edit plus a

summarization).

1. Let it reach a permission request or plan approval.
2. Observe: the prompt takes minutes-to-hours to appear in the extension, while

the session transcript already shows the CLI processed the response; output
trickles in slowly in the meantime.

Combination matrix (only the event granularity varies):

| Client | Upstream | Result |
|---|---|---|
| Terminal (CLI TUI) | same third-party provider | fine |
| VS Code extension | official Anthropic API | fine |
| VS Code extension | same third-party provider | stalls minutes–hours |

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.233

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

Event granularity data (captured from the gateway's request logs, SSE bodies):

| Response | output_tokens | SSE delta events | bytes/event |
|---|---|---|---|
| A | 6400 | 6314 | ~135B (855KB total) |
| B | 3822 | 3803 | ~135B |
| C | 2877 | 2720 | ~135B |

Essentially one event per token; ~99% are thinking_delta with thinking
enabled. The official API batches multiple tokens per delta — 1–2 orders of
magnitude fewer events.

Mechanism (our analysis): the extension processes each stream event
individually — JSON parse → postMessage across the Remote-SSH tunnel to the
local webview → conversation re-render (expensive on long sessions).
Consumption rate falls below the production rate → the CLI's stdout pipe backs
up → the CLI blocks on write → control messages queue behind tens of thousands
of pending events. The unknown message ID error above is consistent with
responses arriving after the CLI had already dropped the request.

Workaround that proves the mechanism: a proxy-level SSE coalescing middleware
merges consecutive same-type content_block_delta payloads into time-windowed
batches (protocol-safe: same index/type only, order preserved). Cutting the
event rate changed only that variable:

• No coalescing: prompt tens of minutes late.
• ~40ms windows (~3–5x fewer events): ~3 minutes late.
• ~500ms thinking window (~23x fewer events): prompt appears within seconds.

Related issues:

• #81425 — identical channel-error log line, different trigger (auto-mode

permission classifier decision never dispatched → infinite hang with no
timeout). Both cases point to the CLI↔webview channel dropping responses
under stress with errors silenced.

• #27808 — another extension-only streaming stall (PreToolUse hook trigger),

not reproducible in the CLI.

Happy to provide more data (event captures, timings) if useful.