[BUG] Session silently terminates after parallel tool_results on Windows v2.1.107 — no error, no API retry, JSONL just ends

Summary

Claude Code CLI v2.1.107 on Windows silently terminates a session after an MCP tool_result is received. No error record, no API call attempt, no crash dialog. The session JSONL simply ends. Subsequent input to the terminal does nothing — the process is dead or wedged.

Distinct from #38437 (that one describes the CLI blocking while waiting for tool_result), #44783 (subagent-level deadlock), and #25979 (SSE streaming stall mid-turn). In my case the tool_result was received successfully and written to disk — the CLI then failed to enqueue the next API request, with no log line of any kind.

Environment

• Claude Code 2.1.107
• Windows 11 Home (10.0.26100)
• Shell: Git Bash 5.2.37 (C:\Program Files\Git\bin\bash.exe)
• Node.js: bundled with Claude Code
• Several MCP servers loaded: playwright, playwright-edge, context7, supabase, unityMCP, n8n-mcp, whatsapp, wp-mcp, gemini-mcp
• Session file was 6.7 MB / 881 JSONL records at the time of the hang
• Model: claude-opus-4-6[1m] (Opus 4.6, 1M context)

Reproduction evidence

Session id: 274589a3-8c3d-4ef0-a3b7-6c9521df2c24
File: ~/.claude/projects/C--Users-somet/274589a3-8c3d-4ef0-a3b7-6c9521df2c24.jsonl

Last four records, in order:

1. 2026-04-14T12:59:58.484Z — assistant text: "Everything confirmed working… Stopping dev server and deploying to prod." stop_reason: tool_use, requestId: req_011Ca3hqQJjdFNdHkLWXqXwD.
2. 2026-04-14T12:59:58.538Z — assistant tool_use for mcp__playwright__browser_close (same requestId).
3. 2026-04-14T13:00:00.803Z — assistant tool_use for Bash (kill dev server, same requestId).
4. 2026-04-14T13:00:05.588Z — user record with tool_result for the Bash call: "killed". Clean success.

After record 4, the file ends. There is no:

• next assistant message,
• API error record (isApiErrorMessage),
• stop_hook_summary,
• turn_duration terminator,
• Windows Application event log crash.

A sibling/sidechain session 28a8a660-537f-4770-9050-a1c5a0c8ff4e.jsonl also ended at 2026-04-14T13:00:13.677Z (~8s later), which suggests the Node process itself went down rather than just one API call failing.

Suspected cause

The assistant emitted two parallel tool_use blocks in a single assistant turn (records 2 and 3 share requestId and id). After both tool_results arrive, the CLI must POST them back as a batched user message. I suspect the batching path drops the turn when:

• the parent JSONL is already large (multi-MB),
• one of the tools is an MCP tool (playwright) and the other is native Bash, and
• the completion timestamps are close together.

A healthy repro of this issue would likely need: a long session (~2 MB+), parallel Bash+MCP tool_use in the final assistant turn, and a subsequent assistant turn expected.

Expected behavior

One of:

• Next assistant request gets POSTed and response written to JSONL, OR
• An isApiErrorMessage record is written so the user knows the turn failed, OR
• A visible error in the terminal so the user can claude resume cleanly.

Actual behavior

Terminal appears idle. No new output. Session unrecoverable without claude resume — and on resume the dropped turn is gone.

Requested

1. Check the tool_result batching code path for silent exceptions when the final assistant turn contains mixed (MCP + native) parallel tool_uses.
2. Ensure every terminal state of a turn writes a JSONL record — at minimum a stop_hook_summary or isApiErrorMessage.
3. Add a stdout/stderr warning when a turn is abandoned without response.

Happy to provide the full 6.7 MB JSONL privately if useful for reproduction.