CLI exits silently when background-task notifications arrive (v2.1.207, Windows 11) - 4x in one day in a background-task-heavy project

Summary

The CLI process terminates silently (no error output, no crash log) at the exact moment background-task notifications arrive. This happened 4 times in a single day in one project; other projects/sessions on the same machine were unaffected. The distinguishing factor is heavy use of background tasks (backgrounded Bash builds/dev servers plus async subagents) in the affected project.

Environment

• Claude Code version: 2.1.207
• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell (primary)
• Hardware: 64 GB RAM (46 GB free at the time), no system-level instability (no reboot/BSOD events in Windows logs during the crashes)

What happens

The terminal session dies mid-turn with no message. Inspecting the session .jsonl transcripts afterwards, all 4 dead sessions end with the same signature: the last records are background-task notification enqueue events (queue-operation / task-notification metadata), then the file just stops — no API error, no isApiErrorMessage, no heap OOM message.

Timeline of the 4 deaths (same day, same project):

| Session | Transcript size | Last records before death |
|---|---|---|
| 1 | 16 MB | 2 task notifications enqueued |
| 2 | 0.5 MB | subagent-completion notification enqueued |
| 3 | 0.6 MB | (ambiguous — coincided with a driver install/reboot, excluded) |
| 4 | 0.34 MB | 2 notifications enqueued 18 ms apart, then nothing; user restarted the CLI 12 s later |

Notes that rule out environmental causes:

• Session 4 died on a freshly rebooted machine, with no GPU/driver events in the Windows System log anywhere near the death, and with no app/child process running (the session had deliberately not launched anything GPU-heavy).
• Windows Application log shows one RADAR_PRE_LEAK_64 WER event for claude.exe (working set grew to ~2 GB) the same day, which may be related for the 16 MB-transcript session, but sessions 2 and 4 were small, so memory growth is not the common factor.
• No Kernel-Power 41, no bugcheck 1001, no display TDR (4101) correlating with any of the 4 deaths.
• Project hooks are all short-lived, non-blocking (exit 0) scripts; the only MCP server is a lightweight stdio Node process (~40 MB).

Suspected cause

A crash or race in the background-task notification delivery path, possibly triggered when two notifications arrive nearly simultaneously (18 ms apart in the clearest case). The affected project is the only one where multiple run_in_background Bash tasks and async subagents run concurrently, which matches "only this project crashes".

Repro (not deterministic)

1. Run several background tasks concurrently (backgrounded Bash commands and/or async Task/Agent subagents).
2. Wait for completions to land close together.
3. Occasionally the CLI process exits silently at notification arrival.

What I could not capture

Claude Code writes no crash log, so there is no stack trace. Happy to run with --debug and attach output if it reproduces — is there a recommended flag set for capturing a native/JS crash at exit?