claude-code - 💡(How to fix) Fix [BUG] Streaming long responses (large plans/markdown) causes Warp terminal to hard-crash on Windows — consider non-streaming or batched flush mode [1 participants]

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.)
2. 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.
3. 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.