Summary
In long sessions on Claude Opus 4.8 (Claude Code CLI), the agent intermittently emits tool calls as literal text in the transcript instead of as executable tool_use blocks. The leaked text is prefixed with a stray count token followed by raw <invoke>…</invoke> XML. The call does not execute, the turn frequently ends immediately, and the malformed markup is shown to the user as the assistant message. Re-issuing the same call verbatim succeeds.
This appears to be the same class of bug as #64108 (which reports a stray court token — court ≈ count), and likely related to #64690, #64418, #64190, #65130, #64561, #64035, #63870, #61122, #63580. Filing a fresh report with a concrete, sustained long-session reproduction.
Symptom (exact)
Instead of an executed tool call, the visible assistant message contains:
count
<invoke name="Edit">
<parameter name="file_path">/path/to/file</parameter>
<parameter name="old_string">...</parameter>
<parameter name="new_string">...</parameter>
</invoke>
Also observed with <invoke name="Bash"> and <invoke name="Write">. Two tells:
- A leading stray
count word.
- The
<invoke> / <parameter> tags are not namespaced (i.e. plain <invoke> rather than the correct internal serialization).
Environment
- Claude Code CLI
2.1.161
- Model: Claude Opus 4.8
- OS: macOS
- Session: very long / high tool-composition — dozens of Edit/Write/Bash calls, 20+ files created across a multi-hour build.
When it happens (pattern)
- Strongly correlated with long / high-composition sessions — frequency rises as the session grows.
- Affects
Edit and Write most, occasionally Bash/Read.
- Intermittent: the same call almost always succeeds when re-issued verbatim immediately afterward.
- When it occurs, the tool does not run and the turn ends ("just exits") with the raw markup as the message body. The user sees a confusing code-dump and nothing happens.
- In my session it recurred ~10+ times over the build.
Reproduction (conditions; not deterministic)
- Start a long Opus 4.8 session in Claude Code CLI.
- Do sustained Edit/Write-heavy work (e.g. scaffolding a project file-by-file with many small Edits/Writes).
- As the session grows, tool calls intermittently serialize as plain
count <invoke>… text instead of executing.
Not reliably reproducible on a single command, but reliably occurs given a long enough Edit/Write-heavy Opus 4.8 session.
Impact
- Heavy transcript noise; reads like a malfunction / random code dump to the user.
- Wasted turns — every occurrence must be detected and the call re-issued.
- Breaks flow in agentic/automated work and erodes user trust.
Hypothesis
The consistent count/court-prefixed, non-namespaced <invoke> corruption points at function-call serialization / tokenization corruption on the model/CLI side rather than a tool-side error — the tools execute fine when the markup is well-formed. Possibly the same root cause as #64418 ("serialized as plain text in high-composition sessions") and #64190 ("after /compact … whole tool calls emitted as <invoke> text").
Observed mitigations (not fixes)
- Re-issuing the call verbatim usually works.
- Starting a fresh / shorter session greatly reduces the frequency.
Summary
In long sessions on Claude Opus 4.8 (Claude Code CLI), the agent intermittently emits tool calls as literal text in the transcript instead of as executable
tool_useblocks. The leaked text is prefixed with a straycounttoken followed by raw<invoke>…</invoke>XML. The call does not execute, the turn frequently ends immediately, and the malformed markup is shown to the user as the assistant message. Re-issuing the same call verbatim succeeds.This appears to be the same class of bug as #64108 (which reports a stray
courttoken —court≈count), and likely related to #64690, #64418, #64190, #65130, #64561, #64035, #63870, #61122, #63580. Filing a fresh report with a concrete, sustained long-session reproduction.Symptom (exact)
Instead of an executed tool call, the visible assistant message contains:
Also observed with
<invoke name="Bash">and<invoke name="Write">. Two tells:countword.<invoke>/<parameter>tags are not namespaced (i.e. plain<invoke>rather than the correct internal serialization).Environment
2.1.161When it happens (pattern)
EditandWritemost, occasionallyBash/Read.Reproduction (conditions; not deterministic)
count <invoke>…text instead of executing.Not reliably reproducible on a single command, but reliably occurs given a long enough Edit/Write-heavy Opus 4.8 session.
Impact
Hypothesis
The consistent
count/court-prefixed, non-namespaced<invoke>corruption points at function-call serialization / tokenization corruption on the model/CLI side rather than a tool-side error — the tools execute fine when the markup is well-formed. Possibly the same root cause as #64418 ("serialized as plain text in high-composition sessions") and #64190 ("after /compact … whole tool calls emitted as<invoke>text").Observed mitigations (not fixes)