[BUG] Bash tool calls emitted as raw <invoke> text instead of executing

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/61367
2. https://github.com/anthropics/claude-code/issues/62344
3. https://github.com/anthropics/claude-code/issues/60584

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

fix it

hey COME here and fix it

it sucks

please fix this, it sucks

please fix this, it sucks

You also encountered this situation, right?

I tried to reproduce and troubleshoot it, but I found that it might be an issue on the model side.

> please fix this, it sucks You also encountered this situation, right? I tried to reproduce and troubleshoot it, but I found that it might be an issue on the model side.

Yes certain convos it happens constantly even on auto mode and it is blocking. It won't stop making the mistake and when prompted, Claude mentioned that it is a problem on the model side and that it can't help itself even though the correct tool call is committed to its memory.

+1 — reproducing the same symptom right now in a long-context session.

Environment

• Model: claude-opus-4-8 (1M context)
• Claude Code (Cowork mode / Code tab)
• Session: ~200k+ tokens of cached context (long article-writing workflow)

Symptom
Across this single session, repeated malformed tool calls with the literal text count appearing right before <invoke name="...">. Failures cluster on Write and Edit for large HTML content (130+ lines), and also hit Read after long free-text preambles. Retries with shorter preambles sometimes succeed, matching the pattern described in #64112.

Reproduction trigger (consistent)

1. Long session (cache-read tokens high)
2. Assistant generates a several-sentence preamble explaining intent
3. Assistant then attempts a Write with a long content parameter
4. The tool call is emitted as raw text starting with count<invoke name="Write">...
5. Harness returns "Your tool call was malformed and could not be parsed. Please retry."
6. Once it happens, it tends to recur within the same session (consistent with the in-context few-shot poisoning hypothesis in #62344)

Workaround that helped (not a fix)
Switching to claude-opus-4-7 mid-session reduced the recurrence, consistent with #64774's finding that 4.7 and Sonnet 4.6 have ~0% failure rate while 4.8 is ~1.5%.

Practical impact
Cost me ~30 retries in one session, and forced a full architectural workaround: moving from "assistant writes long HTML via Write" to "assistant writes short JSON data + a generator script". Effectively gave up on Opus 4.8 for any task with long string parameters.

Filing this as an additional data point. Adding the client-side invariant suggested in this issue (assert structured tool_use when stop_reason == "tool_use") would at least surface the failure earlier instead of letting it cascade.

it disturbe me too

Happening frequently for me with Fable 5.

In my case, I was using an organization login that had denied all tool calls. Ensure in /permissions there isn't a * under the Deny section. Or something similar. Also beware: Claude code would hallucinate tool outputs in this failure mode!

Still there. Can you please fix it? It's ridiculous...

It happens more than 50% of all cmd calls to me, which is extremely annoying. please fix it.

It happens more than 50% of all cmd calls to me, which is extremely annoying. please fix it.

When you first see this mistake, you need to rewind immediately; you cannot let the malformed <invoke> persist in the context window, otherwise the model will enforce this behavior and keep repeating this error.

Hitting this repeatedly with Opus 4.8 — honestly it's getting really frustrating.

A Bash tool call gets emitted as raw <invoke name="Bash">...</invoke> text in the transcript instead of executing. The command never runs; I have to re-issue it. It's intermittent but frequent enough to break flow during multi-step work (repeated git/gh and pytest calls).

Notably, it happened twice in a row while the agent was trying to post this very comment — the gh issue comment tool call itself leaked as raw <invoke> text and did not execute, both times. So the bug reproduces on the act of reporting the bug.

Env:

• Claude Code 2.1.179
• macOS 26.5.1 (arm64)
• Model: Opus 4.8

Matches #67307 (Opus 4.8 specifically). +1 — would appreciate prioritization.

Update — same session, bug fired again (and clustered):

Right after the comment above, the bug misfired again on a gh pr merge call — also twice in a row — the tool call leaked as raw <invoke name="Bash">...</invoke> text and the merge didn't run until the third attempt.

So in a single session it took multiple retries on two separate commands (posting this comment, then a merge) to get one Bash call to actually execute. The intermittency seems to cluster: once a call misfires, the next one or two tend to misfire too, then it recovers.

Env unchanged: Claude Code 2.1.179 / macOS 26.5.1 (arm64) / Opus 4.8. Same root cause as #67307.

This is happening a lot for me lately!

当持续使用较长上下文后，极容易出现，甚至到了连续失败的情况，只能通过Compact或Clear解决。

help me!

I confirm that these errors happen all the time today.

Another repro, this time it killed a whole session (Linux, Opus 4.8).

Same root cause as my earlier reports: a Bash tool call leaks into the transcript as raw <invoke name="Bash">... text instead of executing. I went back through the saved session transcript (~/.claude/projects/<proj>/<id>.jsonl) and the failure pattern is very clear.

Timeline within one session — 4 malformed-call events, in 2 clusters:

| Time (UTC) | Command being attempted | Outcome |
|---|---|---|
| 06:20:55 | CI=true python3 -m pytest tests/... | leaked as raw text, retry succeeded |
| 06:21:19 | gh pr checks 974 --watch | leaked as raw text, retry succeeded |
| 08:28:46 | gh pr create (multi-line body) | leaked as raw text, retry FAILED |
| 08:29:50 | gh pr create (retry) | leaked as raw text, retry FAILED → session stuck |

The terminal entries in the transcript are literally:

The model's tool call could not be parsed (retry also failed).

twice in a row, after which the session could no longer make progress.

What the leaked block looks like in the transcript — the tool call is emitted as assistant text, prefixed with a stray token (call) and truncated mid-stream:

TEXT:call
<invoke name="Bash">
<parameter name="command">cd <project-dir>
CI=true python3 -m pytest tests/tes      <-- cut off here

Confirms the clustering I reported before: once a call misfires, the next one or two misfire too. Both failure clusters here are pairs of consecutive misfires; in the 06:20 cluster the retry recovered, in the 08:28 cluster it did not and the session was lost.

Common trigger in every misfire here: gh / long multi-line Bash commands (pytest pipelines, gh pr checks --watch, and especially gh pr create with a multi-line body). Single short commands in the same session were fine.

Env:

• Claude Code 2.1.183
• Linux 5.15.0 (x86_64)
• Model: Opus 4.8

So this is not macOS-specific — reproduces on Linux too, and is severe enough to end a session (not just cost a retry) when two consecutive gh pr create calls both misfire. Same family as #67307.

Same here. I’m seeing this frequently with Opus 4.8[1m].

The model seems to intend a tool call, but the tool invocation leaks into the visible text as plain text instead of being emitted as a structured tool_use. The command is not executed, and the turn simply ends.

This happened for me in a long 1M-context session, and sometimes it even appears when the context is very sparse.
My solution is to use the /goal mode.

Seeing what looks like the same root cause (tool-call intent leaking into the text channel
instead of a structured tool_use block), but with a different failure mode worth adding here.

In my case, only the leading call token of the <invoke ...> block leaks — and then it
degenerates into a repetition collapse: a single assistant response emitted \n\ncall
~32,000 times (a ~256 KB text block).

Environment

• Claude Code (CLI), inside a tmux session, macOS
• Model: Opus 4.8 (1M context) — claude-opus-4-8[1m]
• Long multi-turn coding session with many consecutive Edit/Read/Bash tool calls

Evidence (from the session .jsonl, code/prose redacted)

The call string is stored inside the text field of type:"text" blocks (not a tool_use
block), same as this issue — just truncated to the first token and then repeated:

"type":"text","text":"<redacted prose>\n\ncall\n\ncall\n\ncall\n\ncall ... (repeated ~32000 times)"

Per-turn count of call inside type:"text" blocks, chronological (shows the escalation):

3, 1, 3, 31977, 1, 1, 1, 1, 1, 1, 1, 2

Reproduced locally with:

grep -o '"type":"text","text":"[^"]*"' <session>.jsonl | grep call

Relationship to this issue

• #63870: the full call + <invoke name="Bash">...</invoke> XML leaks as text → not executed.
• This variant: only the leading call leaks, then loops into \n\ncall ×~32k.

Both look like the same underlying problem (legacy XML tool-use format mixing into the JSON
response, cf. #49747), differing only in how much of the block leaks and whether it then collapses
into repetition.

Notes

• Correlates with long context (the collapse happened deep into a long session, consistent with the

high cache-read tokens others reported).

• No tool was mis-executed and no data was corrupted — the call is plain text.
• No project source code is needed to reproduce; all code/prose redacted above.

Adding a data point: still reproducing on 2.1.196 (Opus 4.8 1M), so the regression persists well past the 2.1.156/2.1.158 transcript above.

Environment

• Claude Code 2.1.196
• Model: Opus 4.8 (1M context)
• Windows 11 Pro / PowerShell (primary shell; failures occur on Bash tool calls)

Symptom matches this issue exactly — an intended Bash tool call is emitted as plain assistant text instead of a structured tool_use, so nothing executes and the turn stalls. Same leaked shape:

count
<invoke name="Bash">
<parameter name="command">cd "...worktrees/review-pr-270" && git branch --show-current && gh pr view 270 ... </parameter>
<parameter name="description">...</parameter>
</invoke>

Stray-token variant: in my case the leaked prefix token is count (vs the call/court reported here and in #68354). Same failure, different garbled token — consistent with the "adjacent-vocab token selected instead of the antml:invoke opening tag" theory.

Trigger correlation: clusters in long, tool-call-heavy sessions — specifically PR-review / merge-gate workflows that chain many git + gh commands with && in a single Bash call. Short/fresh sessions rarely hit it.

Workaround that reliably works for me: retry once or twice; if it sticks, /clear or a new session clears it (the malformed shape does not recover within the same session).

Same with ollama and qwen3.5:9b-q4_K_M.

Still reproducing on 2.1.197 with claude-opus-4.8