Recurring error: "The model's tool call could not be parsed (retry also failed)" interrupts sessions

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/62123
2. https://github.com/anthropics/claude-code/issues/62467
3. https://github.com/anthropics/claude-code/issues/63719

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

same

Confirming this on Opus 4.8 + Claude Code v2.1.159 (WSL2 / Windows 11) — same environment as the report, one patch newer. Adding a concrete client-side signature in case it helps narrow the repro.

The malformed tool call has a consistent textual shape. When it fails, the assistant emits a stray literal token on its own line immediately before the tool-call opening, and the antml: namespace prefix is dropped:

count
<invoke name="Bash">

(instead of the correct opening sequence with the antml: prefix). The harness parser requires the exact opening sequence, doesn't find it, and returns "malformed and could not be parsed." The whole block then becomes plain text. The stray token is most often the literal word count, but I've seen other short tokens too.

Correlation with the context that precedes the tool call (matches @shenxiu's "longer turns / non-ASCII / quotes / code" observation):

• Strongly correlated with long turns — failures cluster late in long sessions.
• Strongly correlated with high special-character density in the immediately preceding context — in my case Swedish å/ä/ö, nested quotes, shell escapes (2>/dev/null), and base64 blobs. One failure occurred only ~6% into a session, but immediately after a context injection containing ~1668 escapes + ~485 non-ASCII chars.
• Every real failure I've inspected has the exact form <stray-token>\n<invoke name="..."> with the antml: prefix missing.

Note for debugging: the malformed blocks are never persisted as assistant content in the transcript — the parser discards them, so only the "malformed" message remains. That means --debug / transcript exports won't contain the raw failed payload; it has to be captured at the parse layer before the block is dropped. That may be why no one's been able to attach a raw example yet.

Possibly related (separate failure mode, same week): I also hit a phantom user message injected right after /clear that the model then acted on — UserPromptSubmit hooks fired on text I never typed. Same signature as the now-locked #29233, still present in v2.1.159. Flagging it here only because it's a second distinct parse/state failure on the same build; happy to file it separately if useful.

same problem

same, how can I solve it

same problem

same problem

same

any method to solve it

same problem

同样的问题
same problem

The same problem

The same problem

The same problem, sonnet works fine

The same problem

The same problem

same problem

same issue.

same issue.

v2.1.160

The problem persists, and it is no longer functioning properly.

The same issue.
One session Failed ten times,can't continue.

The same issue. One session Failed ten times,can't continue.

same

Workaround: use an English or French session instead of Chinese / Japanese

First-person data point supporting the non-ASCII trigger suspected here: I kept hitting
The model's tool call could not be parsed (retry also failed) while working in Chinese.
Opened a new session in French, worked normally ~30+ min, no recurrence.

CJK is fully multi-byte non-ASCII, which seems to push tool-call arguments past whatever
flips the decoder / breaks the partial-JSON parser. Anecdotally, the reports I've seen on
X/Twitter also skew toward Japanese- and Chinese-speaking users. Consistent with #49747
(format-mix) and openclaw/openclaw#59076 (CJK streaming parse).

Workaround: hit it → start a new session in English or French and continue there.
Code comments / commit messages can stay in your own language; just keep what lands
inside tool-call arguments in ASCII.

Observed correlation, not a proven root cause.

Env: Claude Code 2.1.160, model claude-opus-4-8[1m] with high effort, macOS.

Updated: ~3 hours without the errors in 3 projects :)

FYI — a partial workaround based on turn ordering

In heavy use I've noticed the failure correlates with interleaved thinking/text followed by a tool_use in the same turn (the tool_use block gets dropped). As a practical mitigation I've been structuring turns so the tool call comes first:

• ❌ conversation/thinking → tool_use (same turn) → frequently drops
• ✅ tool_use → conversation/text → much more stable
• ✅ tool_use → tool_use (chained) → stable

i.e. emit the tool call up front, then talk.

The key upside: this needs no config/setting changes and works in the current session as-is. You don't have to drop 1M→200k, switch models, lower effort, or start a fresh session (all of which lose something — context, capability, or history). Throughput drops a bit, but "slower" beats "unusable."

Reordering so that no long thinking/text precedes the tool_use noticeably reduces "retry also failed" for me (Opus 4.8, heavy CJK/Japanese args, 1M context). Not a fix — drops still happen occasionally — but it cuts the frequency a lot. Sharing in case it helps others triage. 🙏

Another data point: macOS + Opus 4.8[1m] + Japanese (CJK) — and notably NOT length-dependent, at max effort

Same The model's tool call could not be parsed (retry also failed). Adding two angles I haven't seen yet in this thread.

Env: Claude Code 2.1.161 (also reproduced on earlier builds), claude-opus-4-8[1m], max effort, macOS (Apple Silicon). Recurs across completely unrelated tasks over several days — both MCP/browser-heavy sessions and plain Read/Edit sessions — so it's clearly task- and tool-independent, consistent with the model-serving-variant theory in #61133.

1. NOT correlated with session length, at least for me. A failure just killed a short session — it died on the 2nd–3rd tool call (a Read → Edit → Read on a single file), not deep into a long accumulated session. This matches @wilhelmsson424-jpg's "only ~6% into a session, right after a non-ASCII-heavy context injection" observation. The better predictor for me is non-ASCII / CJK density in the tool-call arguments and the immediately preceding context, not turn count. My entire system/rules context is Japanese, and the call that died was an Edit whose old_string/new_string were Japanese + nested quotes — i.e. peak multi-byte density. Consistent with @qfdk's CJK note.

2. Reproduces at max effort — one tier above the high reports in this thread. Mechanistically this lines up with @f-mofujiwara's observation that a long interleaved thinking/text block followed by a tool_use in the same turn gets the tool_use dropped: max effort produces the longest pre-tool-call thinking, i.e. the widest drop window. Anecdotally, lowering effort to high/medium on tool-/edit-heavy turns reduces the frequency for me (not a fix).

Confirms the existing workarounds: starting a fresh session clears it immediately (consistent with re-rolling the server-side routing bucket from #61133), and switching to Sonnet 4.6 never reproduces it (matches @duzefu). Still present on 2.1.161 for Japanese-language workloads.

**Data point: Swedish (Latin-1 diacritics å/ä/ö) — non-ASCII does not trigger it constantly the way CJK does**

Adding a nuance to the non-ASCII theory that the CJK reports above (@qfdk, @Jamesdddxxx) point at.

Env: Claude Opus 4.8 [1M], Windows 11 (WSL2 Ubuntu), recent v2.1.15x builds. I work almost entirely in Swedish, so every session is heavy with Latin-1 diacritics (å/ä/ö), nested quotes, SSH escapes, and 2>/dev/null-style shell args.

Observation: I hit this maybe ~2 times over a couple of weeks of constant Swedish-heavy use — and had zero recurrence over the last 24h despite normal heavy usage. So Latin diacritics clearly raise the probability (consistent with the non-ASCII suspicion) but do not reproduce it deterministically the way CJK appears to for Chinese/Japanese users.

Interpretation: this looks like a gradient, not a binary. Latin-1 diacritics add ~1 extra byte per char; CJK is fully multi-byte. That's consistent with a "character-byte-density pushes tool-call arguments past some decoder/partial-JSON threshold" model rather than "any non-ASCII breaks it." The fact that it's intermittent even under sustained non-ASCII load fits that — you have to cross a density/length boundary, and Latin diacritics get you there far less often than CJK.

Signature when it does happen (Windows/WSL): the failed tool call emits a stray literal token on its own line immediately before the invoke tag, and critically the antml: namespace prefix is dropped — so the parser can't match the opening sequence and the whole block degrades to plain text. The malformed block is never persisted as assistant content in the transcript (the parser discards it), which is why nobody can attach a raw payload — there's nothing logged on the client side to attach.

Supports @f-mofujiwara's turn-ordering workaround: structuring turns as tool_use → text (call first, talk after) instead of text → tool_use has been noticeably more stable on my end too, with no config changes.

(Earlier forensic detail from us is in https://github.com/anthropics/claude-code/issues/63875#issuecomment-4590125775.)

Same issue here, and it's a hard blocker when running many long-lived sessions.

Environment

• Model: Opus 4.8 — started only after switching to 4.8; did not happen before
• Claude Code: 2.1.161
• OS: Windows 11

Symptom — once it starts, every subsequent tool call is corrupted and it does NOT self-correct:

• the function-call opening tag garbles into a meaningless token (e.g. count)
• arguments leak into the conversation as raw text (e.g. a filename printed inline)
• MCP is fine (/mcp = Connected) — not a tool/server problem

It's self-reinforcing: the model seems to "learn" the malformed pattern from its own corrupted output in history and keeps reproducing it. Critically, the model is not aware the calls are failing — it behaves as if they succeeded.

Triggers (observed, non-deterministic): long sessions / large accumulated context; tool args with non-ASCII content (we work primarily in Japanese).

Recovery that works for us:

• /compact reliably fixes it (history is replaced by a summary that no longer contains the malformed examples)
• /rewind to a checkpoint before the corrupted turn also helps and is lighter
• --continue does NOT help (it restores raw history including the corrupted examples → symptom returns)
• /clear as last resort

Impact: running many always-on sessions, this means manually patrolling for stuck sessions and /compact-ing each one — significant ongoing cost. Falling back to Opus 4.7 (where #61133 was fixed) avoids it entirely, which points to a 4.8-specific regression.

Happy to provide verbose logs if you point me to where they're written.

same

same

same

same

same

same

same

same

Same issue here on Opus 4.8 max. This has made Claude completely unusable for me, and I hope it can be fixed as soon as possible. Thanks.

same problem

same problem

Same !

Same~~

same...;(

Same

same problem

same ~

Same phenomenon here on Opus 4.8 (1M context).

I can confirm the language correlation @qfdk pointed out: it fires far more often in Japanese / non-ASCII-heavy sessions, and the failures cluster in longer turns. Matches @wilhelmsson424-jpg's signature — the antml: prefix gets dropped from the <invoke> opening (sometimes with a stray short token on the preceding line), so the harness parser can't find the exact opening sequence and discards the whole block.

Switching the working language to English/French largely avoids it, which lines up with the workaround above.

Judging by past track records, it often takes weeks for Anthropics dev team to realize and resolve critical issues. just like that history deletion incident back then.

We're currently facing another fatal bug in Claude Code Opus 4.8. Since it’s severely impacting our time and budget, I’m directly pinging Anthropic staff for immediate attention.

@alfredxing @alii @chloeanT @cirospaciari @controversial @domdomegg @felixrieseberg @k6l3 @lovesegfault @Mic92 @natemcmaster @palcu @tengyifei

same problem

still exists~

Same corruption on macOS (Apple Silicon) — likely model-level, not Windows-only

Adding a macOS data point, since this issue is tagged platform:windows but also area:model.

I hit the "count"/"court" token-corruption variant described in this writeup: the opening tag of a tool call was replaced by the bare word court, and the call's arguments leaked into the chat as raw text instead of being executed. As reported there, it did not self-recover — once it appeared, subsequent tool-result rendering kept degrading until the context was reset.

Environment
| | |
|---|---|
| Model | Claude Opus 4.8 (1M context) — claude-opus-4-8[1m] |
| OS | macOS 26.5.1, Darwin 25.5.0, arm64 (Apple Silicon) |
| Claude Code | 2.1.80 |
| Node | v25.9.0 |
| Shell | zsh |

Trigger context (matches other reports)

• Long-running session with large accumulated context
• Tool arguments containing heavy non-ASCII (Japanese) text
• Opus 4.8 specifically (the analogous 4.7 bug #61133 is reportedly fixed)

Why this matters: the corruption reproduces on macOS/arm64, not just Windows — consistent with the area:model label. Suggest broadening the platform scope.

Workaround that helped: /compact or /clear to reset the corrupted history and stop the self-mimicking loop. /rewind before the first corrupted turn also works.

Happy to provide raw logs of the corrupted tool-call payload if useful.

Another data point: reproduces on WSL2 (Linux), not only native Windows — and is intermittent with recovery

Confirming this on:

• Claude Code: v2.1.161
• Model: claude-opus-4-8 (Opus 4.8)
• OS: WSL2 / Linux (5.15.167.4-microsoft-standard-WSL2) — notably not native Windows, which several reports here single out as a trigger
• Language: Japanese (non-ASCII) text in tool arguments and conversation
• Session shape: long-running; the failing turn alone spanned ~40 min and ~290 messages

Symptom (matches this issue): the function-call opening tag is emitted corrupted — as the literal token count — immediately followed by the raw tool-call markup leaking into the assistant's text output instead of a structured tool call, e.g.:

count
<invoke name="Read">
<parameter name="file_path">…/some/file.ts</parameter>
</invoke>

The tool is never actually executed (it's plain text), and the model proceeds as if it had succeeded.

Two observations that may help narrow the cause:

1. It reproduces on WSL2/Linux, so the trigger is not Windows-specific. Common factors in my case were Opus 4.8 + Japanese tool arguments + a long accumulated turn.
2. In a single ~40-minute session the corruption fired 3 times intermittently, and the model recovered to correct structured tool calls in between each occurrence (not a permanent one-way break in this instance). The corrupted token was count in all three. The final occurrence happened the moment it tried to issue a tool call right after a long turn, which is what ended the useful work.

Recovery via /rewind / /compact matched what others reported. Happy to provide more redacted detail if useful.

Same. It happens after Opus 4.8 upgrade.

Too many mistakes waste a lot of time and make it impossible to continue the work.

Claude Code: v2.1.168
Model: claude-opus-4-8 (Opus 4.8)
OS: macOS 26.5.1
Effort: ultratcode

same here

omg same 4.8 😂

This is annoying.

>call
>invoke name="Read"

Also reproduces on macOS (Apple Silicon) — and on both Opus 4.7 and 4.8 (1M tier), not Windows/4.8-only

Adding a macOS data point, since this issue is currently labeled platform:windows. We hit this repeatedly on macOS, so the trigger does not appear OS-specific.

Correction (edited): an earlier version of this comment said "never observed on Opus 4.7." That was wrong — checking our own logs, we first captured this on Opus 4.7 (1M context) (2026-05-29, live screen captures) and it has continued on Opus 4.8 (1M). So in our experience it is not exclusive to 4.8, and downgrading to 4.7 did not make it disappear. Both 1M-context tiers are affected.

Environment

• Claude Code 2.1.163
• Model: Opus 4.7 (1M) and Opus 4.8 (1M) — both affected
• macOS (Apple Silicon)
• Sessions that are (a) long-running / high accumulated context and (b) have non-ASCII (Japanese) text in tool arguments (file contents, bash strings, commit messages, etc.)

Symptom / signature

• A tool-call opening tag corrupts into a stray plain-text token — we've seen e.g. court / a literal <invoke name=" leaking into the assistant's visible text instead of producing a real tool call — and the harness then reports "The model's tool call could not be parsed (retry also failed)."
• Critically it self-reinforces: once one corrupted tool-call lands in the history, the model mimics that corrupted format on subsequent turns, so the error recurs every turn until the corrupted examples are removed from context.

Trigger combination

Opus 1M-context tiers (4.7 and 4.8) + long accumulated context + non-ASCII (Japanese) tool arguments. The platform:windows label looks incidental — we reproduce on macOS. This combination (heavy context + Japanese tool args) may explain why reports cluster among Japanese-language users rather than a specific OS or model version.

Recurrence

Repeated independent occurrences over several weeks on our heaviest Japanese-language, high-context session (a tool-call-dense workload).

What mitigates it for us

• /compact (or /rewind) breaks the self-reinforcement loop by removing the corrupted examples from context. A plain --resume / --continue of the raw history re-triggers it (the corrupted examples come back).
• Frequent proactive compaction + decomposing work into shorter turns (lighter context) reduces frequency.
• Keeping individual tool-call payloads small / low in special-character density helps.
• (Model downgrade to 4.7 did not help us — both tiers are affected.)

Happy to provide a sanitized transcript snippet of the corruption if it would help narrow the root cause.

same phenomenon here on Fable 5.....

same here

same here

Using /compact more often solved this error for me

same here

same here

same here

Hit the same bug and dug through my local session transcripts (~/.claude/projects/.../*.jsonl). Sharing concrete forensic data in case it helps narrow the root cause — including an answer to your "where is the failed payload logged" question.

Environment (mine)

• Claude Code: 2.1.181 (also saw it once on 2.1.154)
• Model: Claude Opus 4.8 (1M context) (claude-opus-4-8)
• OS: Windows 11 Pro (build 10.0.26200), PowerShell — same platform as the report
• Entrypoint: cli, extended/interleaved thinking enabled

Frequency in one session

In a single ~30-minute session I got the injected retry prompt 3× and the terminal The model's tool call could not be parsed (retry also failed). 2× (20:01–20:10). Each terminal failure silently ended the turn — I had to manually re-prompt. The two dropped turns had turn_duration of 273 s and 98 s, so a lot of work was burned and discarded.

Forensic signature in the transcript (answers "where is the payload logged")

On every failed turn the persisted assistant record looks like this:

• stop_reason: "tool_use" — the model did intend to call a tool
• a thinking block of length 0
• no tool_use block at all
• but usage.output_tokens is non-trivial: 3505, 1328, 887, 827, 702 on the five failed turns

So the model clearly generated a tool call (hundreds–thousands of output tokens, stop_reason=tool_use), but the harness could not parse it and persisted only an empty husk. The raw malformed tool-call payload is not saved anywhere in the transcript — only the empty thinking block + output_tokens > 0 remain. That zero-length-thinking + stop_reason=tool_use + missing tool_use is the reliable fingerprint of this failure if you want to grep for it.

The harness then injects a synthetic user turn Your tool call was malformed and could not be parsed. Please retry., the retry reproduces the same empty result, and it gives up after one retry with the synthetic assistant message (isApiErrorMessage: true, model: "<synthetic>").

Correlations I can see

1. Model-correlated, not platform-only. I have ~15 sessions in the same Windows/PowerShell project. On Opus 4.7 (versions 2.1.132–2.1.144) the signature appears zero times. The first occurrence is on Opus 4.8 (2.1.154, 2026-05-28) and it becomes acute on 2.1.181. Same OS, same shell, same kind of tasks throughout — the only thing that changed is the model.
2. Always immediately after a thinking block. Every malformed call follows an extended-thinking block. On the failed turns that thinking block is empty (len 0).
3. Not tied to one tool. The tools in play around the failures were Read, Glob, AskUserQuestion, and PowerShell — not a single offending schema. One hard failure happened on the very next turn after an AskUserQuestion was answered.
4. Single retry is the weak point. In the one 2.1.154 case the first retry succeeded and the turn recovered. The 2.1.181 cases failed because both the initial call and the single retry produced the same unparseable output — i.e. retrying once with no change to the request just reproduces the failure.

Suggestions

• Persist the raw malformed tool-call payload (even truncated) to the transcript / a debug log. Right now it is completely lost, which is exactly why nobody can attach a concrete example.
• Consider >1 retry and/or nudging the request on retry (the identical re-prompt reproduces the identical failure).
• The empty-thinking + stop_reason=tool_use husk suggests the parse failure may be in tool_use arguments emitted right after a thinking block under Opus 4.8 — worth checking the interleaved-thinking + tool_use parsing path specifically.

Happy to share raw .jsonl excerpts (with paths redacted) if useful.

same here

same

same here

same

Same problem here, and the babysitting got old, so I wrote a small Stop hook that auto-recovers from it. The failure is the model emitting a tool call as plain text (usually dropping the antml: namespace prefix) — the harness can't parse it, the built-in retry also fails, and the turn just ends.

The hook detects that specific end-of-turn state and feeds the model a short "re-issue that call correctly" nudge so the session continues on its own instead of stalling. It varies the wording each time (to avoid the model repeating the same mistake) and caps auto-retries before handing back to you. Python stdlib only, MIT, fail-safe (any error → it does nothing).

Unofficial workaround, obviously — it treats the symptom, not the parser. Repo: https://github.com/mufanq/claude-code-toolcall-recovery

FYI:
This bug not only CC, but olso claude.ai (web) and the PowerPoint add-on, too.
In other words, it is not an issue specific to "Claude Code."

same

same. It's really annoying.
macOS and Windows, claude code 2.1.195 (VS code plugin), Opus 4.8

Opus 4.7 works fine in the same environment.

same issue

เมื่อไหร่จะแก้ สูน

Workaround: I've switched to Sonnet 5 (MAX) instead of Opus, sacrificing cost-performance, to avoid this issue.