[BUG] Interactive text streaming never paints incrementally on Windows — reproduces even off-platform (fresh WSL2/Debian/xterm)
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?
Related to #37110 ("Line-by-line Streaming mode disappeared?", closed stale). Still present in 2.1.218, and I now have evidence it's not platform/terminal-specific.
Symptom: in interactive mode, assistant text only appears all at once when a response completes — never incrementally — even for 60+s/2000+ token generations. 100% reproducible, every session.
Transport is fine: --output-format stream-json --include-partial-messages shows real content_block_delta events arriving continuously over the full generation (measured, not bunched at the end). So this is display-side, not network.
Elimination matrix (all ruled out individually):
- Renderer: fullscreen and classic
- Shell: PowerShell 7/5.1, cmd
- Daemon vs in-process backend
- Version: 2.1.210, 2.1.217, 2.1.218
- Model: Haiku, Sonnet, Fable
- Network: no proxy, no TLS inspection
- Terminal emulator: Windows Terminal, bare ConPTY (via pywinpty, no terminal emulator in the loop at all), and xterm under WSLg
- OS platform: native Windows AND a from-scratch WSL2 + Debian install (
process.platform === 'linux', never touches ConPTY) WT_SESSION/WT_PROFILE_IDenv leaking into WSL viaWSLENV(checked directly — empty, unsetting made no difference)- The client's streaming-watchdog non-streaming-fallback path (
CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK) — confirmed via source that this only triggers on connection errors and always appends a visible "Response stalled" warning, which never appears here, so it isn't the mechanism
Since the exact same symptom reproduces across completely disjoint OS/terminal/network stacks on the same account, the one variable never isolated is the account/session itself — pointing at a server-side gate (GrowthBook flag / cohort / rollout condition) rather than anything client-side. Filing this in case someone can check account-level flags for text-streaming rollout.
Happy to provide any diagnostic — this reproduces 100% of the time on demand.
What Should Happen?
Assistant response text should paint incrementally as it's generated (as it did in earlier Claude Code versions, and as it still does for other users on Windows 11 per #51743), matching the incremental content_block_delta events already confirmed to arrive over the wire.
Error Messages/Logs
No error messages — this is a silent display issue, not a crash. Supporting evidence instead (timestamps of content_block_delta events proving the transport streams fine while the interactive UI still paints only at completion):
▎
▎ 1784759627.581 stream_event message_start
▎ 1784759628.089 stream_event content_block_delta
▎ 1784759629.316 stream_event content_block_delta
▎ 1784759630.984 stream_event content_block_delta
▎ 1784759632.218 stream_event content_block_delta
▎ 1784759633.611 stream_event content_block_delta
▎ 1784759635.691 stream_event content_block_delta
▎ 1784759637.306 stream_event content_block_delta
▎ 1784759639.008 stream_event content_block_stop
▎ (deltas spread continuously over ~12s — captured via --output-format stream-json --include-partial-messages)
Steps to Reproduce
- Run claude interactively (any shell/terminal — reproduces on Windows Terminal, bare ConPTY, and xterm under WSL2)
▎ 2. Ask for a long response, e.g. "write a 500-word essay about X"
▎ 3. Observe: the spinner/token counter climbs normally during generation, but the response text only appears all at once when generation completes — never incrementally, even for 60+ second generations
▎
▎ Compare with claude -p "<same prompt>" --output-format stream-json --include-partial-messages, which shows the underlying content_block_delta events arriving continuously (proving the transport streams fine — this is display-side only).
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.218 (also reproduced on 2.1.210 and 2.1.217 — identical behavior across all three)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Decisive test: captured the interactive renderer's raw output via a bare ConPTY (Python pywinpty, no terminal emulator involved at all) and timestamped every never-before-seen word in a ~600-word essay. Result: 228 novel words all appeared in the same one-second window, ~15s after the prompt — the renderer emits the entire response in a single paint, confirmed independent of any terminal emulator.
▎
▎ Also ruled out (in case these come up): the client's non-streaming-fallback watchdog (CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK) — checked the source, this path only triggers on connection errors and always appends a visible "Response stalled" warning, which never appears here, so it isn't in play. Also ruled out WT_SESSION/WT_PROFILE_ID leaking into WSL via WSLENV — checked directly, was already empty, no effect either way.
▎
▎ Given this reproduces identically across native Windows and a from-scratch WSL2/Debian install (different OS, different terminal, same account), the account/session itself is the one variable in common across every failing test — suggesting a server-side gate rather than a client bug. Happy to run any diagnostic on request, this reproduces 100% of the time.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗