[BUG] Streaming long responses (large plans/markdown) causes Warp terminal to hard-crash on Windows — consider non-streaming or batched flush mode

Summary

Long streamed responses from Claude Code (e.g. multi-KB plans / markdown)
reliably hard-crash the Warp terminal on Windows. Investigation of Warp logs
shows Warp emits one INFO event per terminal character, the log floods, and
the process is killed with no panic or minidump.

The root cause sits in Warp's renderer/log path, and I've filed it there as
warpdotdev/warp#9899.
Filing here too because Claude Code's character-by-character streaming is
the trigger, and a coarser flush mode or a --no-stream interactive
option would let users on affected host-terminals keep working while Warp
fixes the underlying issue.

Environment

• Claude Code: latest as of 2026-05-02
• Host terminal: Warp v0.2026.04.27.15.32.stable_03 on Windows 11
• Reproduces consistently on long-output turns

Reproduction

Issue a prompt that asks Claude Code to produce a long response in the
terminal (e.g. "generate a multi-phase implementation plan, intermediate
review, then re-plan remaining phases"). Within seconds of the stream
starting, Warp dies. Three crashes in ~50 minutes on this workload.

The exact prompt I used (verbatim — nothing sensitive in it):

You were interrupted mid operation. Please check the progress you made so far. I want you to resume. I want you to also make the plan to plan in all phases that were still pending, intermediate critical review of the state of the phase you just finished, and even in the face itself if it's a big face and complex. Plan so accordingly. but write the plan to MD, because there is currently a bug with the warp cli we are using that makes it crash.

Adding the "write the plan to MD" instruction at the end was itself a
workaround attempt — but the first response token Claude Code prints
(acknowledging the request, listing files it will read, etc.) is already
enough to crash Warp on subsequent turns when output is long.

Suggestions

1. output: file — let me ask the agent to write its main response to

a file and only print a one-line summary to the terminal. (Possible
today via prompting, but turning it on globally would be safer.)

1. Batched flush mode — add an env var or setting that buffers output

and flushes once per N ms / N tokens / on newline, rather than per
character. Would dramatically reduce the per-character event load on
any host terminal, not just Warp.

1. Detect known-bad host terminals — when $TERM_PROGRAM == WarpTerminal

on Windows, default to a coarser flush until upstream fixes
warpdotdev/warp#8409 / warpdotdev/warp#9899.

Related

• warpdotdev/warp#8409 —

Warp hangs at >100% CPU when Claude Code runs (same workload, hang
variant).

• warpdotdev/warp#9899 —

My new report of the Windows hard-crash variant.

Workaround

Asking the agent to write long output to a markdown file (as in the prompt
above) reliably avoids the crash.