claude-code - 💡(How to fix) Fix Regression (since 2026-05-29): intermittent "tool call was malformed and could not be parsed" — tool_use block absent on a stop_reason=tool_use turn

Summary

Intermittently, on a turn that includes a tool call, the next turn becomes the harness error:

Your tool call was malformed and could not be parsed. Please retry.

…instead of the assistant continuing. To the user this looks like the agent thought for a while and then silently did nothing — no result, no success/failure, as if the instruction was ignored. In many cases the tool had already executed and returned output, yet the malformed error still fired on the following turn, wasting the round.

This issue includes transcript-level forensics (below) that I believe identify where the breakage is, plus data showing this is a clean regression that started on a specific date.

Environment

• Claude Code: 2.1.158
• OS: macOS (Darwin 25.4.0)
• Model: claude-opus-4-8 (confirmed from message.model in the JSONL transcripts; sessions ran in 1M-context mode)
• effortLevel: xhigh (see "Possible contributing factors")

This is a regression that started 2026-05-29

Counting occurrences of could not be parsed across all of my historical transcripts (~/.claude/projects/**/*.jsonl):

  0 occurrences   before 2026-05-29   (oldest transcript: 2026-04-23)
 57 occurrences   2026-05-29          ← first day it appears
 15 occurrences   2026-05-31

This is not sparse-data noise. In the window 2026-04-23 → 2026-05-28 there were 32,173 assistant turns with stop_reason == "tool_use" and zero parse failures. The error appears for the first time on 2026-05-29 and immediately occurs 57 times that day. Something changed on/around that date.

Scope

Not isolated to one session or workspace. Affected transcripts:

 8 sessions   project: linkup
 4 sessions   project: cc
 1 session    project: demob
 1 session    project: user-center
 ----
14 sessions across 4 projects

Transcript-level forensics (addresses the open question)

The original report asked whether the root cause is the model emitting invalid tool-call JSON, or the harness mishandling the continuation. The recorded transcript points at the assistant tool-call turn itself.

Window around one failure (role / stop_reason / content-block-types):

turn N-2  assistant  stop_reason=tool_use   content=[tool_use(Bash)]      ← normal call
turn N-1  user       -                      content=[tool_result]         ← tool ran, output returned OK
turn N    assistant  stop_reason=tool_use   content=[thinking]            ← stop_reason says "I'm calling a tool"
                                                                            but NO tool_use block is present
turn N+1  user       -                      content=[]                    ← injected "could not be parsed" error

The key anomaly is turn N: the assistant turn declares stop_reason == "tool_use" (i.e. "I am about to call a tool"), but its content array contains only a thinking block — the tool_use block is missing/absent. The parser then fails (retry also fails) and the round is discarded.

So the observable failure is: a tool_use-terminated assistant turn whose tool-call payload is absent or unparseable, which the harness records with the thinking block preserved and the tool_use block gone. This is consistent with the user-visible symptom — a long "thinking" phase (amplified by effortLevel: xhigh) followed by nothing.

Key observations

• Occurs only on turns that include / should include a tool call — never on plain conversational turns.
• No correlation with command type or complexity. Triggered after a trivial Read (file_path + offset + limit, zero escaping) and after complex inline node -e / jq Bash — while other calls in the same session (gh issue create, gh repo view) did not trigger it. (An earlier version of this report guessed the trigger was nested quotes / regex escaping in Bash — that hypothesis was wrong.)
• The tool often already executed and returned output; the malformed error fires on the following turn regardless.
• Non-deterministic within a session: some tool turns trigger it, others don't, with no clear relation to content.
• Net effect: a wasted retry round → perceived latency / "agent stopped responding / ignored me."

Reproduction (observed pattern)

1. Assistant emits a tool call (Bash, Read, etc.); the tool executes and returns output.
2. On the next assistant turn, instead of continuing, the harness injects "Your tool call was malformed and could not be parsed. Please retry."
3. Inspecting the transcript, that assistant turn has stop_reason=tool_use but its content holds only a thinking block, no tool_use block.
4. Intermittent — no reliable content-based trigger.

Expected behavior

Either:

• The tool-call parser robustly handles (or recovers) the assistant's tool-call output instead of discarding the turn, or
• The error states what specifically failed to parse (and ideally preserves/logs the raw tool_use payload), so the failure is actionable rather than a silent dead-turn.

Possible contributing factors

• effortLevel: xhigh produces long thinking blocks; every captured failure has a thinking block immediately before the missing tool_use. Worth checking whether long-thinking + tool_use serialization is involved.
• Sessions ran in 1M-context mode with a large tool surface (multiple MCP servers + many skills), i.e. very large prompts. Worth checking whether the failure rate correlates with prompt/context size.

I'm happy to share sanitized transcript excerpts for any of the failing turns.