[Bug] Tool-use blocks corrupted with prepended "count" token, causing parse failures

Bug Description
## Title Tool-use blocks intermittently corrupted by an injected literal token ("count") prepended to <invoke>, causing "tool call could not be parsed" and turn abort ## Severity High — blocks all tool execution intermittently. Renders the agent unable to run Bash, edit files, manage tasks, or call MCP tools for the duration of the failure. Forces the user to run every command manually. ## Environment - Model: Opus 4.8 (1M context) — exact id claude-opus-4-8[1m] (shown in CLI status line as Opus 4.8 (1M context)) - Client: Claude Code CLI - OS: Linux (Ubuntu/GNOME terminal) - Mode: auto mode on - Effort: max - Date observed: 2026-06-19 (and recurring for the prior 4–5 days) - Session id (from status/title context): 04b0fd32-f312-4a25-a56f-a12f3d67533f ## Summary When the assistant emits prose immediately before a tool-use block, the rendered/serialized tool call is corrupted: a literal token count appears on its own line at the very start of the tool block, immediately above <invoke name="...">. The malformed structure fails to parse, the harness returns "Your tool call was malformed and could not be parsed. Please retry.", and the turn aborts WITHOUT executing the tool. Retrying reproduces the same corruption. The user confirmed via screenshots that the assistant's visible output literally contains: count <invoke name="Bash"> <parameter name="command">...</parameter> ... </invoke> i.e. the word count is glued to the front of the tool block. The assistant did not intend to write that token; it appears to be injected at serialization/render time. ## Scope (NOT tool-specific) Reproduced across multiple, unrelated tools in the same session: - Bash (git status/merge/push commands) - Edit (editing a local markdown file) - TaskUpdate (updating the task list) - MCP mcp__claude_ai_Supabase__execute_sql (Supabase query) Because it spans built-in tools AND an MCP tool, this looks like a serialization/streaming layer issue, not a problem with any individual tool schema. ## Reproduction (observed pattern) 1. Assistant writes one or more sentences of explanatory prose. 2. On the same turn, assistant attempts a tool call immediately after that prose. 3. The serialized tool block comes out with a leading count token before <invoke>. 4. Harness: "tool call could not be parsed". Turn ends, tool never runs. 5. Automatic retry → same corruption. Correlation noticed (not proven): the failure is strongly associated with prose appearing directly before the tool block. Turns that go straight to a tool with little/no preceding prose sometimes succeed; turns with a paragraph of prose before the tool reliably failed. The token is always count (never a different word), which suggests a specific code path / placeholder rather than random truncation. ## Impact / workarounds - Hard block: the agent cannot self-execute any tool while this is occurring. - Workaround that worked: the user ran the commands/SQL manually in a real terminal and pasted output back. (Secondary issue surfaced here: pasting long multi-line commands into the user's terminal got line-wrapped/mangled, so single-line commands run one-at-a-time were needed — but that's the user's terminal, separate from this bug.) - Workaround that did NOT reliably work: emitting the tool with no preceding prose — helped sometimes, failed other times. ## What I'd expect Tool-use blocks should serialize cleanly regardless of surrounding assistant prose; no placeholder/literal token should ever be prepended to <invoke>. ## Diagnostic notes for the team - The literal token is consistently the word count. Grep the streaming/serialization layer (and any tool-call assembly / token-counting or function-calling shim) for a count symbol or label that could leak into the output buffer ahead of the tool block. - Worth checking whether this is specific to the 1M context Opus 4.8 variant (claude-opus-4-8[1m]) and/or to long contexts (this session was at ~74–78% context when failures occurred). - Worth checking interaction with auto mode classifier and with MCP tool invocation, since both built-in and MCP calls were affected. - Screenshots available from the user showing the verbatim corrupted output for Bash, Edit, TaskUpdate, and the Supabase MCP call. ## Frequency Reproducible and persistent across ~4–5 consecutive days, not a one-off.

Environment Info

• Platform: linux
• Terminal: vte-based
• Version: 2.1.181
• Feedback ID: 56a43bdc-9055-4e6d-81b7-7e824d428a14

Errors

[]