[Bug] Opus 4.8: Tool calls serialized as plain text instead of tool_use blocks in high-composition sessions

Bug Description
Title

Opus 4.8: assistant narrates a tool call as plain text (<invoke …> / call …) but emits no tool_use block — recurs in tool-dense sessions, near-absent in single-tool sessions

Environment

• Claude Code CLI: 2.1.159
• Model: claude-opus-4-8 (1M context) — claude-opus-4-8[1m]
• Platform: macOS 26.5 (build 25F71), arm64 (Apple Silicon)
• Not observed on Opus pre-4.8 (user has run prior versions extensively; symptom is new to 4.8).

Symptom

Mid-turn, instead of emitting an actual tool_use block, the assistant outputs tool-call-like TEXT into the visible message body and ends the turn. The tool never runs; the session looks stalled until the user re-prompts. Observed leaked forms include:

• <invoke name="...">…</invoke> rendered as literal text
• lines beginning call / invoke
• AskUserQuestion called with no questions parameter (validation error), twice consecutively
• This is the same family as the "batched tool-result delivery anomaly": earlier in the same session, several Bash calls returned empty output, then flushed all at once in a delayed batch with trailing noise.

Reproduction signal — the key new data point

Strongly correlated with TOOL COMPOSITION, not just session length.

• Recurs in daily/cadence orchestration sessions: heterogeneous high-density tool use in single turns — Bash (external CLIs: git, gh, python, ffmpeg, custom scripts), MCP tools loaded dynamically via ToolSearch (Gmail, Calendar, Drive, Slack, chrome-in-browser), WebSearch/WebFetch, image Read, large tool outputs (47-channel Slack history dumps, HTML diffs).
• Near-absent in project/coding sessions: predominantly Read/Edit/Write, one tool type at a time, little-to-no dynamic MCP loading.
• The user runs both session types daily and reports the split is consistent and reproducible.

Frequency rises after: (a) a large preceding tool output in context, and (b) a tool whose schema was just dynamically loaded via ToolSearch. Long transcript + many prior tool-heavy turns aggravates it (consistent with #63880).

Frequency / severity

• This single session: ~6–8 occurrences across the turn sequence.
• Severity: medium — every occurrence stalls the workflow and forces a manual "you did it again, retry" re-prompt. High annoyance in long working sessions.

Hypothesis (user + assistant, for triage)

Streaming tool-call emission/parsing regresses under high tool-call diversity + dynamic schema loading + large interleaved tool outputs. The decode path occasionally serializes the tool-call as text tokens instead of a structured tool_use block. Single-tool-type sessions rarely hit the triggering condition, which is why coding sessions are clean and cadence/orchestration sessions are not.

Workaround

None that prevents it. Only recovery is user re-prompt ("retry"); the assistant cannot self-detect (it cannot observe its own malformed output post-hoc). A Stop-hook regex guard can flag a likely leak after the fact but cannot prevent it.

Related issues

• anthropics/claude-code #63880 — "Advisor narrates but fails to make tool calls" (claude-opus-4-8, open)
• anthropics/claude-code #61133 — Opus tool calls "could not be parsed" (since 2026-05-20)

Environment Info

• Platform: darwin
• Terminal: Kaku
• Version: 2.1.159
• Feedback ID: 76b3b325-370c-4e4a-a2aa-e68dbe265414

Errors

[]