[BUG] VS Code Remote SSH webview falls far behind Claude output due to unthrottled thinking_tokens and stream events

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?

Bug Description

When using the Claude Code VS Code extension through Remote SSH, the chat
webview can fall tens of seconds behind the actual Claude process.

The model finishes successfully and the session JSONL already contains the
complete response, but the currently open webview continues displaying old
thinking content very slowly. Closing and reopening the Claude session makes
the complete response appear immediately.

This indicates that generation and persistence are working, while the live
extension-to-webview message/rendering path is backlogged.

Environment

• Claude Code VS Code extension: 2.1.177
• VS Code Server: 1.124.2
• Connection: VS Code Remote SSH
• Remote OS: Linux x64
• Thinking effort: max
• Model/provider: Anthropic-compatible provider
• Local VS Code usage does not appear to reproduce the problem

Steps to Reproduce

1. Connect to a Linux server using VS Code Remote SSH.
2. Open the Claude Code extension.
3. Use max thinking effort.
4. Send a prompt that produces a moderately long thinking response.
5. Observe that thinking appears extremely slowly, sometimes fewer than five

visible Chinese characters per second.

1. Wait until the backend has completed.
2. Close and reopen the Claude session.
3. The complete thinking and final response appear immediately.

Observed Behavior

The live webview falls behind the Claude process. In captured extension logs,
the webview reported input lag values including:

• 63,448 ms
• 31,096 ms
• 9,736 ms

These delays also occurred with the unmodified official extension before any
custom streaming workaround was enabled.

With partial messages disabled, a small isolated response still emitted 499
system/thinking_tokens messages, while the thinking and text content were
only delivered as completed assistant blocks.

With partial messages enabled, one response emitted approximately:

• 1,802 thinking_delta events
• 1,802 thinking_tokens events
• 1,236 text_delta events

Many events arrived less than 1 ms apart.

The extension serializes messages to the webview, so high-frequency token
status and delta events appear able to starve the final assistant/result
messages and webview rendering.

What Should Happen?

Expected Behavior

• Thinking and text should remain close to the backend stream.
• The webview should not accumulate tens of seconds of lag.
• Final assistant/result messages should be processed immediately.
• Closing and reopening the session should not be required to see completed

output.

Suggested Fix

1. Coalesce thinking/text deltas to one update per animation frame or every

50-100 ms.

1. Throttle thinking_tokens updates to approximately every 300-500 ms.
2. Give final assistant/result messages priority over queued progress events.
3. Mark the session idle from the extension/backend when the result arrives,

rather than depending only on a potentially stalled webview.

1. Add sequence numbers or a current-state snapshot so a lagging webview can

discard stale progress events and catch up.

1. Consider enabling partial messages for Remote SSH after adding batching and

backpressure.

Confirmed Workaround

A local process wrapper that:

• enables partial messages,
• batches thinking/text deltas every 80 ms,
• throttles thinking-token updates to 500 ms,
• flushes pending batches before final messages,

substantially reduces the event count while preserving the exact thinking and
text contents.

This suggests the issue is in event delivery/backpressure and webview update
frequency rather than model generation or session persistence.

Error Messages/Logs

Steps to Reproduce

1. Install Claude Code VS Code extension version 2.1.177.

1. Use VS Code Remote SSH to connect to a Linux x64 server.

1. Open the Claude Code extension panel on the remote server.

1. Set the thinking effort to max.

1. Start a new Claude Code session and send a prompt likely to produce a long

thinking response, for example:
Analyze why a VS Code Remote SSH webview may fall behind a backend process
when thousands of small streaming events are sent. Think thoroughly and
provide a detailed final answer. Do not use tools.

1. Keep the Claude Code session panel open and observe the thinking output.

1. Notice that the visible thinking output progresses extremely slowly,

sometimes fewer than five Chinese characters per second, or remains
unchanged for an extended period.

1. Wait several minutes without stopping the task. The Claude backend may

already have completed and persisted the response, while the open webview
remains behind.

1. Close only the Claude Code session tab or panel. Do not terminate VS Code or

the remote Claude process.

1. Reopen the same Claude Code session.

1. Observe that the complete thinking content and final response now appear

immediately.

1. Open View -> Output, select the Claude Code output channel, and look for

an input_lag_sample event. In my environment, recorded values included:

``
input_lag_sample durationMs=9736
input_lag_sample durationMs=31096
input_lag_sample durationMs=63448
``

1. Repeat the same test using VS Code locally instead of Remote SSH. The issue

does not reproduce, or is substantially less severe.

No project files or source code are required. The issue can be reproduced in
an empty remote folder and appears to be caused by the extension-to-webview
streaming path under Remote SSH.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.177

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_