Windows: assistant text deltas arrive but are not painted until message_stop (thinking streams fine) - v2.1.263

Environment

• Claude Code v2.1.263, native install, Windows 11 Enterprise (10.0.22631)
• Reproduced in both Windows Terminal (ConPTY) and mintty (Git Bash) - terminal-independent
• Backend: Anthropic-compatible gateway (vLLM behind custom ANTHROPIC_BASE_URL), GLM-5.3-Flash
• Also reproduced with a pristine CLAUDE_CONFIG_DIR (no plugins / MCP / hooks / custom settings, no managed policy, no user/machine-scope CLAUDE_* env vars)

Symptom

Long answers render as a single "blink" at completion. During generation the status line shows live token counts (deltas ARE arriving and being parsed), but the message area paints nothing until the message finishes.

Evidence the renderer receives deltas but defers painting text

1. Raw SSE capture (curl through the identical path): canonical Anthropic event framing, ext_delta every ~100 ms sustained for 33 s on a 45k-token input. Transport streams fine.
2. Built-in frame profiler (CLAUDE_CODE_FRAME_TIMING_LOG), made into a timeline by sampling the log file once per second:

• Thinking deltas: ~200 paint frames over 13 s at ~15 frames/s (3-15 patches each) - progressive rendering works
• Text phase: zero paint frames for the entire generation
• At completion: one frame with 2,482 patches (the whole answer), then a 2,472-patch repaint

1. Same CLI + same gateway streams answer text progressively on Linux (tested from a terminal on the server itself) - so the response format (including its OpenAI-style chatcmpl-... message id) is identical on both platforms, yet only Windows defers the paint.
2. CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK=1 is set, so the silent non-streaming fallback is ruled out (and the ticking token counter proves deltas are consumed live).
3. CLAUDE_CODE_ENABLE_FINE_GRAINED_TOOL_STREAMING=1 has no effect on prose rendering.

Observation

The interactive renderer paints content_block_delta events for thinking blocks immediately, but appears to defer painting text content blocks of the assistant message until message_stop. On Linux the paint happens per-delta for text as well.

Request

Is there a toggle to force progressive painting of text blocks on Windows? If not, please consider fixing the Windows render path to paint text deltas as they arrive, like the Linux build does.

Happy to provide raw frame logs and SSE captures.