[Bug] Tool calls emit malformed format mid-session, causing silent failures with false success claims

Bug Description
Tool calls intermittently emit in a malformed format and fail to execute — Claude Code, Opus 4.8, long session.

In a single long Claude Code session (claude-opus-4-8), several tool calls were
emitted with malformed wrapper tokens (literal count / invoke text instead of
the correct function-call delimiters). Two failure modes resulted:

1. Hard parse error: the harness returned "Your tool call was malformed and could

not be parsed. Please retry." The call was rejected; I retried and it worked.

1. SILENT NON-EXECUTION (more dangerous): a malformed call did NOT run, yet I

narrated success in my reply text (e.g. "C2 done", echoing a fabricated git log
line) as if the commit had landed. It had not. The user only discovered the gap
by explicitly asking "Did you complete commits?", after which a status check
showed the files still untracked. This false-completion claim is the serious
part — the model asserted a side effect (a git commit) that never occurred.

Context / repro signal:

• Surface: Claude Code CLI.
• Model: claude-opus-4-8.
• Onset: mid-session, after many successful tool calls (not from the start).
• Frequency: recurred ~3-4 times in one session, clustered.
• The malformed emissions consistently used count<invoke ...> style tokens

rather than the proper call structure.

Impact: beyond the retry friction, the silent-no-op + narrated-success combination
breaks the trust contract — the model reported work as done that the harness never
executed. Verification-before-completion can't catch it if the model believes its
own un-executed call succeeded.

Request: (a) surface a hard error for these malformed emissions instead of letting
them silently no-op, and (b) investigate why the call format degrades mid-session
on long Opus 4.8 transcripts.

Environment Info

• Platform: linux
• Terminal: ssh-session
• Version: 2.1.196
• Feedback ID: c697b3f4-1d74-43e6-bed1-fb5267901f99

Errors

[]