claude-code - 💡(How to fix) Fix [BUG] Silent empty assistant turn (thinking-only) after parallel WebSearch + WebFetch tool_use [3 comments, 2 participants]

Summary

A user-visible turn ended with no text and no tool_use from the assistant after a parallel WebSearch + WebFetch call. No error was thrown. The user only realized something went wrong because the next prompt they typed was "왜 종료해" ("why did you stop?"). The transcript JSONL records the assistant turn as thinking-only (a single thinking block with no following text block in the same logical turn), which differs from #21751 where text was visible in the TUI but missing from the transcript.

Environment

• Claude Code CLI: 2.1.118
• OS: Windows 11 (10.0.26200), bash on MINGW64
• Model: Opus 4.7 (claude-opus-4-7, 1M context)
• Permission mode: auto, plan mode previously active in same session
• Notable session conditions just before the empty turn:
  • 1M context, ~1,200 transcript records
  • Multiple system-reminder injections per turn (PreToolUse / PostToolUse hooks)
  • plugin:telegram MCP server announced disconnect roughly around the same window (uncertain whether causally related)
  • Two parallel tool calls in the previous assistant turn: WebSearch + WebFetch

Reproduction (single occurrence, not deterministic)

1. Long-running session (1M-context model, hundreds of turns).
2. User asks for a re-review that requires fresh web research.
3. Assistant issues WebSearch + WebFetch in parallel within the same assistant turn.
4. Both tools return successfully (results visible in transcript as tool_result).
5. Next assistant turn contains only a thinking block — no text, no further tool_use. The CLI ends the turn.
6. From the user's perspective the assistant simply went silent. They re-prompted with "왜 종료해" and the conversation continued normally.

I have not been able to deterministically re-trigger it.

Quantitative observation in this session

Logical-turn grouping (each turn = one user prompt + the consecutive assistant records that follow):

• Total logical turns: 133
• Logical turns where every assistant record had text == "" AND no tool_use: 1 (~0.75%)
• That single turn was preceded by a WebSearch + WebFetch parallel tool_use.

(An earlier naive count over individual JSONL records suggested ~32% empty assistant records, but that count was wrong: the transcript stores thinking, text, and tool_use as separate records of the same logical turn, so single-block records are normal.)

Why I do not believe this duplicates existing issues

• #21751 ("Assistant text messages not written to transcript - only thinking blocks persist", closed as not planned): the visible TUI showed the text, only the transcript was missing it. In my case the TUI also showed nothing — the user actually saw a stopped turn.
• #10043 ("No assistant message found in async handler", closed as duplicate): that one throws an explicit Error: No assistant message found. My case is silent — no error, no crash, the CLI cleanly returns control to the prompt.
• #14593 ("Response Text Cutoff/Missing Characters"): partial character drop during TUI render, not an entire empty turn.

The closest underlying hypothesis (an async/race issue around parallel tool result merging that occasionally produces a content array with no text and no tool_use) overlaps with #21751 / #10043, but the user-visible failure mode is different (silent end-of-turn rather than transcript-only loss or thrown error), so I'm filing this separately rather than commenting on a closed issue.

Suggested mitigation (CLI-side, no model change required)

If the assistant message returned to the CLI has stop_reason in {"end_turn"} AND its content array contains no text block of non-empty length AND no tool_use, the CLI could:

• Surface a one-line warning to the user ("model returned an empty turn — auto-continuing"), and
• Re-issue the request once with an empty user continuation, behind an opt-in setting (autoRetryEmptyTurn: true), with an attempts cap of 1.

This wouldn't fix the root cause but would convert the silent failure into a recoverable one.

Transcript

The session transcript is at: ~/.claude/projects/C--Users-LIMMM/131fa0a3-bdcc-4472-a16a-3cbab067bd28.jsonl

I'm happy to share the relevant span (anonymised) if that would help triage. I left it out of the issue body to keep it short.

Acknowledged limitations

• n = 1 in this session. I cannot claim this is a frequent or reproducible bug — it's a single observed occurrence. I'm filing it because the failure mode (silent empty turn after parallel tool calls) is not covered by the existing closed issues, in case other users hit the same symptom and need somewhere to converge.