Opus 4.8: tool-call block opening tag corrupted to a near-token (court/count/caught), causing unparseable tool calls and fatal turn stops

Summary

When Claude Opus 4.8 emits a tool call, the special opening tag for the tool-call block is sometimes corrupted into a near-neighbor token — observed variants: court (22 occurrences), call (12), count (10), caught (3), co (3). The subsequent <invoke> / <parameter> XML structure is entirely well-formed. Because the opening tag itself is corrupted, the harness parser cannot recognize the block as a tool call, and it is instead exposed as literal text in the assistant message.

Harness behavior on corruption

• The harness detects the malformed tool call and injects: "Your tool call was malformed and could not be parsed. Please retry."
• The model retries, but the corrupted output from the prior attempt remains in context as part of the assistant message. The model appears to imitate this corrupted pattern on retry, sometimes re-corrupting the tag.
• If the retry also fails, the harness emits a synthetic message: "The model's tool call could not be parsed (retry also failed)" with stop_reason: stop_sequence, and the turn terminates (fatal stop).

Frequency

• 13 sessions / 50 occurrences / 13 fatal turn stops.
• Across claude-opus-4-8 assistant messages: 50 occurrences out of 7,525 total assistant messages = 0.66% of messages.

Model specificity

All 50 occurrences are on claude-opus-4-8. For the same user, no occurrences were found on:

• claude-opus-4-7 (2,640 messages)
• claude-fable-5 (926 messages)
• claude-sonnet-5 (152 messages)
• claude-sonnet-4-6 (53 messages)

Environment

• Claude Code desktop (CCD), version 2.1.197
• macOS (Darwin 24.6.0)
• entrypoint: claude-desktop

Correlations (suggestive only, not confirmed causal)

• Edit tool involved in 25/50 occurrences.
• A single block containing multiple batched <invoke> calls in 14/50 occurrences.
• Payload content skewed toward Japanese-heavy markdown (tables, bold text, full-width brackets/parentheses).
• Output truncation was observed in 0/50 occurrences — this does not appear to be a length-limit issue.

Reproduction example

• Session dated 2026-07-06T00:04 (session file 19c3c79f-04cc-4d1c-8c50-243bbf284705.jsonl): an Edit tool call targeting docs/INDEX.md was exposed as literal text due to the corrupted opening tag. On retry, the model expanded the call into a 3-call Edit batch and re-corrupted the tag the same way, leading to a fatal stop.

Impact

• The in-progress turn is lost when a fatal stop occurs.
• Because retries are conditioned on the corrupted prior output still present in context, the failure does not self-recover — the model tends to imitate the corruption pattern rather than escape it.

Requested action

• A model-side fix for the tag corruption itself, and/or
• A harness-side mitigation that masks or strips the corrupted output from context before a retry attempt, so the retry is not conditioned on the malformed pattern.

---
🤖 Generated with Claude Code