Summary

On Windows, Warp is hard-killed (no Rust panic, no Sentry submission, no
crashpad minidump) when an interactive TUI agent — in my case Claude Code —
streams a large response (e.g. an LLM-generated implementation plan, a few
hundred lines). The log fills with one INFO event per character
(warp::terminal::view::action::TerminalAction::TypedCharacters) and then
just stops mid-line. SQLite WAL recovers ~hundreds of frames on the next
launch, confirming an unclean shutdown.

Likely related to #8409 (Warp hangs >100% CPU when Claude Code is running) —
this report is the harder failure mode of the same workload on Windows:
instead of hanging, the process is killed.

Environment

• Warp version: v0.2026.04.27.15.32.stable_03 (Stable channel, Windows)
• OS: Windows 11 Home, build 26200
• Shell: PowerShell 5.1 + Git Bash via Bash tool
• TUI agent: Claude Code (anthropic-ai/claude-code) running in foreground

Reproduction

1. Open Claude Code in a Warp tab.
2. Issue a prompt that produces a large streamed response. Mine was a planning
   request that asked Claude to "resume work, intermediate-review the previous
   phase, and re-plan all remaining phases." (≈ multi-KB markdown stream.)
3. Watch the response stream in. Within a few seconds → tens of seconds, Warp
   disappears (no dialog, no error).
4. Relaunch Warp — startup log shows crash recovery child process killed
   and SQLite WAL recovery.

I reproduced this 3 times in ~50 minutes today on the same workload.

Evidence (from %LOCALAPPDATA%\Warp\Warp\data\logs\)

Four log rotations in 17 minutes (08:37 → 09:11 → 09:15 → 09:25). Three
ended abruptly mid-stream; one was a clean menu-close.

Tail of a crashed log — process simply stops, no shutdown sequence:

2026-05-02T09:25:30Z [INFO] dispatching typed action: warp::terminal::view::action::TerminalAction::TypedCharacters
2026-05-02T09:25:30Z [INFO] dispatching typed action: warp::terminal::view::action::TerminalAction::TypedCharacters
2026-05-02T09:25:30Z [INFO] dispatching typed action: warp::terminal::view::action::TerminalAction::TypedCharacters
[…log file ends here…]

Compare with a clean shutdown (file rotation via Settings → quit) on the
same day — full teardown sequence is logged:

2026-05-02T09:24:55Z [INFO] dispatching action for "root_view:close_window"
2026-05-02T09:24:55Z [INFO] No windows left, terminating app
2026-05-02T09:24:57Z [INFO] application will terminate
2026-05-02T09:24:57Z [INFO] Shutting down SQLite writer thread
2026-05-02T09:24:57Z [INFO] Tearing down app services...
2026-05-02T09:24:57Z [INFO] Uninitializing crash reporting...

Next-launch markers confirming unclean exit:

[WARN] SQLite error 283 (A WAL mode database file was recovered): recovered 449 frames from WAL file …\warp.sqlite-wal
[INFO] Initializing crash reporting … with tag "v0.2026.04.27.15.32.stable_03"...
[INFO] Successfully drew 10 frames; killing crash recovery child process
[WARN] Failed to record conversation with ID <redacted-uuid> because it was missing an initial query

Notes / Hypotheses

• Logging emits one INFO event per terminal character. For a multi-KB stream
  this is tens of thousands of dispatches/sec. The renderer + SQLite writer
  • log writer compete for the same time budget. Plausible failure modes:
    GPU watchdog reset, OOM, or a panic on a thread without crashpad coverage
    (no .dmp produced).
• No .dmp file is generated → Sentry never receives the crash. Worth
  checking whether the log/render path runs on a thread Crashpad doesn't
  cover on Windows.
• A coarser flush (debounce or batch TypedCharacters per frame) would
  likely fix both this crash and the hang in Warp hangs for minutes, consuming >100% CPU when Claude code session is running - unhangs when the claude is finished with the job #8409.

Workaround I'm using

Asking Claude to write the long output to a file instead of streaming it
to the terminal avoids the crash entirely.

I have 3 captured crashed sessions with full sanitized logs (secrets,
UUIDs, and username scrubbed). Happy to share the files privately or attach
them here if useful for triage — just let me know.