[BUG] Opus 4.8 repeatedly emits malformed tool_use blocks, entire response discarded (4.7 works fine)

Correction on environment info: the actual operating system is Windows 11 (10.0.26200), not Linux. The repro was on native PowerShell / Windows Terminal, not WSL. The "Ubuntu/Debian Linux" selection in the form was a mistake on my side.

For completeness:

• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell 5.1
• Claude Code: 2.1.156
• Model: claude-opus-4-8[1m] (broken) vs claude-opus-4-7[1m] (works)
• MCP servers active during repro: plugin:telegram, plus several claude.ai connectors (Notion, Gmail, Calendar, Drive, Apple Watch Health bridge, etc.)

我的macos上面也会出现这样的问题 并且我还有一台windows也会出现 现在我认为是模型层的问题 他不会固定发生 而是偶尔就会发生,伴随的症状就是简单的任务长时间思考 并且任务无法确定是否会完成

Adding observations from a heavy-MCP environment (Figma / Gmail / Calendar /
Drive / Playwright-CDP / Android, plus ~10 custom skills) that may extend
the failure mode described above.

Repro context:

• Model: claude-opus-4-8
• Claude Code: 2.1.158, Windows 11
• ~15 MCP tools active, ~6k token system/skill stack
• Failure becomes near-deterministic after 5-10 turns, matches OP

What I observe in the broken responses (split into two patterns):

Pattern A (~70% of failures): raw XML in text block
The model emits its tool call as plain text containing the internal
<function_calls> / <invoke name=\"...\"> / <parameter name=\"...\"> XML,
inside a regular text content block, instead of as a structured tool_use
block. stop_reason is still set to tool_use, but the response contains
zero tool_use blocks — only thinking and text. This matches the
symptom in #61133 (closed) but is now reappearing in Opus 4.8.

Pattern B (~30% of failures): silent truncation
Response contains only a thinking block and terminates. No text, no
tool_use. stop_reason still reports tool_use.

Possible retry-loop amplifier:
After a Pattern A failure, subsequent responses in the same session
increasingly contain broken <function_calls> fragments appended to
otherwise-normal text output (e.g. partial tags like <function or
stray closing >). This looks like prior malformed XML being re-fed
into context via retry annotations, which then primes the model to
emit more of the same — a latch effect. Starting a fresh session
breaks the loop; in-session retries do not.

Workaround that works for me:

• Hard rule: 2 malformed responses in a session → start a new session

immediately (do not retry in-session)

• Fall back to Sonnet 4.6 for MCP-heavy workflows (0 failures observed

on the same prompts and tool surface)

• Opus 4.7 also works as a fallback per OP, but I'd recommend Sonnet 4.6

if A/B routing (#61133) is a concern

Happy to share sanitized JSONL transcripts of both patterns if useful.

Same symptom reproducing on the claude.ai chat web/mobile app (not just Claude Code), today (June 7, 2026).

Setup: Opus 4.8, Project-external chat, long memory context (~20 user-edit entries), multiple consecutive tool calls (memory edit + web search).

Symptom: assistant response stream terminated immediately after tool calls. User saw an empty assistant turn with no text and no error message. Reproduced multiple times across consecutive tool calls in the same conversation. Repeated 500-char validation retries on the memory tool seemed to correlate with the cut-offs.

Resolution: switched to Opus 4.7 mid-conversation. Worked immediately with the same context and same tool-call patterns — confirming the model is the variable, not the environment.

Adding this as a data point that the malformed-tool-use / response-discard behavior is not Claude-Code-specific — it surfaces in Anthropic's hosted claude.ai chat surface as well, with the same workaround (pin to 4.7).

This bug is making Claude Code completely unusable for real work.

When the tool_use XML corruption occurs mid-session, there is no way to resume the interrupted task — especially for non-technical users who don't use git. The entire context is lost with no recovery path.

This isn't a minor annoyance. It breaks workflows entirely. A paying Max plan subscriber cannot rely on Opus 4.8 for any serious coding session because at any moment, hours of work can be wiped out with zero recourse.

This bug has been open and unassigned for weeks. That is unacceptable.

We need either:

1. A fix for the XML corruption bug, OR
2. A session recovery mechanism so work can continue after the crash

Until one of these exists, Opus 4.8 is not fit for production use. Please treat this as a critical priority.

Additional note on environment:

• OS: Windows 11
• Language: Japanese (tool arguments frequently contain multi-byte / non-ASCII characters)
• Model: Claude Opus 4.8 (1M context)

Japanese Windows users appear to be disproportionately affected by this bug. There are numerous reports on Zenn, note, and X (Twitter) describing this as a daily occurrence — yet almost none of those users have filed English-language GitHub issues. The actual scale of impact is likely far larger than the issue count suggests.

Based on community reports, the combination of long context + multi-byte characters + multiple MCP servers significantly increases the reproduction rate on Japanese Windows environments. Please consider this as a specific reproduction condition worth investigating.

+1 from Japan (Tokyo region, Claude Max 5x, Claude Code v2.1.170, VS Code extension).

To correct a common framing in this thread: this regression did not start with 4.8. The earliest related report I can find is #62467 (2026-05-26, Opus 4.7 + extended thinking, unparseable tool_use). 4.8 made it catastrophic, but 4.7 was already showing the same failure mode under extended thinking + long context. Downgrading to 4.7 is a stopgap, not a cure.

My session log (2026-06-13):

• Two consecutive sessions on Opus 4.8 collapsed into memory-confusion ("混濁"): tool calls malformed, /continue dragged the corrupted state forward, model stopped responding entirely. Forced restart.
• Downgraded to claude-opus-4-7. Manageable, but the same pattern can still surface in long Edit-heavy sessions.
• One empirical observation worth investigating: sessions that started on Fable 5 and switched to Opus 4.8 mid-stream did NOT exhibit the confusion. Pure-4.8 sessions did. Whatever Fable 5 anchors in the context window seems to suppress the failure mode in 4.8. That's a diagnostic lead.

Why this is hitting Japanese users especially hard:

• Fable 5, the documented workaround, has been geo-blocked from Japan since 2026-06-11 (#68129) with no graceful fallback — it just silently disappears from /model.
• That leaves paid Max 5x subscribers in JP with two doors: a broken Opus 4.8, and an Opus 4.7 that's already showing the same regression in long sessions.
• This is no longer "intermittent inconvenience." It's billable client-delivery hours being burned. Three weeks of reports on the same root cause with no fix is not a normal pace for a flagship paid product.

The reason you're not seeing more reports from Japan is not absence of the problem — it's cultural reluctance to file English bug reports. Please don't read silence as satisfaction.

Ref:

• Zenn writeup of the same symptom cluster: https://zenn.dev/edhiblemeer/articles/claude-code-opus48-tool-corruption
• Earliest related: #62467 (4.7, 2026-05-26)
• Cross-symptom: #66112 (output written to thinking), #64977 (long-session corruption), #68156 (still recurring 2026-06-13)

Corroborating report — Opus 4.8 (claude-opus-4-8, pinned), reproduced 6+ times in a single session. Same malformed tool_use symptom as this issue.

Environment:

• Model: claude-opus-4-8 (pinned via project .claude/settings.json)
• Client: Claude Code CLI on Windows 11, bash shell
• Session: moderate length (a design/planning session)

Symptom:

• Tool-call blocks emitted as bare <invoke>/<parameter> tags WITHOUT the antml: namespace, with a spurious "court" token prepended. The harness treats them as body text, so the tool never runs ("malformed tool call could not be parsed", or a silent no-op stall).

Trigger / non-trigger (observed):

• Markedly higher failure rate when a message contains prose BEFORE the tool call in the same message. Emitting the tool call as the first element of the message succeeded reliably across many calls.
• NOT caused by line endings (CRLF/LF) or payload size — also reproduced on a Read whose call carried no file content.

Workarounds that held for us:

• Put the tool call first in the message; one tool call per message.
• Once a malformed call enters the history, the session appears unrecoverable (consistent with #62344 few-shot poisoning) — a new session is the only reliable recovery.

Possibly related: #60584 (court token, closed), #64314 (count token), #64235 (regression since 2026-05-29), #62344 (few-shot poisoning, closed), #66400.

I’m a Japanese macOS user and often work with non-ASCII text.

The malformed-output problem became much more frequent after I started building a library for Runic characters. I generally avoided entering Runic characters directly into prompts because they could trigger security filters, and used plain-text files when I needed to exchange actual Runic text. Even so, I observed more malformed tool calls and unexpected interruptions during that work than in any other session.

The most severe case occurred in a separate session. I started a new conversation with Fable, asked it to write a hook to mitigate the problem, and included malformed XML from an earlier session as part of the problem description. That session deteriorated rapidly. It produced substantially more malformed output and failed Multi-Edit calls than any other session I have observed. It was the strongest case of few-shot self-poisoning I have seen: once the malformed XML was present in the context, similar malformed structures appeared repeatedly and did not clear on their own within the session.

Quantitative cross-model data point (local transcript scan)

Corroborating this. I parsed message.model across my local Claude Code transcripts and counted, per model: (a) assistant turns emitting ≥1 tool_use block (denominator), and (b) "malformed / could not be parsed" events attributed to the failing turn's model. Same machine, overlapping workloads, across CC 2.1.156 and 2.1.170:

| model | tool-call turns | malformed | rate |
|---|---:|---:|---:|
| claude-opus-4-8 | 9,320 | 141 | ~1.5% |
| claude-opus-4-7 | 5,122 | 0 | 0 |
| claude-sonnet-4-6 | 2,288 | 0 | 0 |
| claude-fable-5 | 983 | 0 | 0 |
| claude-opus-4-6 | 241 | 0 | 0 |

• Failing-turn signature matches the reports here: stop_reason == "tool_use" but the content array contains only a (often empty) thinking block and no tool_use block.
• ~71% recover on the automatic retry; ~29% end in "retry also failed" and the turn is lost.
• Concentrated in long sessions and in turns with large/complex tool arguments (figure/doc generation, large multi-file edits). It spans two CC versions, so updating CC did not change it for me.
• Switching off opus-4-8 (e.g. Sonnet 4.6) avoids it entirely in my data — consistent with the "4.7 works fine" reports.

Happy to share the scan script if useful.

+1 — same symptom on Windows 11 + Japanese (ja-JP) locale, Claude Code Desktop v1.15962.1, model claude-opus-4-8.

Reproduction (minimal, not requiring long context or MCP):

• From session start, every Agent tool call (subagent_type=general-purpose, opus model) is rejected by the harness with "Your tool call was malformed and could not be parsed. Please retry."
• All other tools (Bash, Read, Write, Edit, Grep, WebFetch) work fine in the same session.
• Switching to /model claude-opus-4-7 immediately resolved it — completed a 9-task subagent-driven workflow (TDD + reviewer per task) end-to-end with no parse failures.

Adding a Windows + non-English-locale data point: the regression doesn't appear to depend on macOS, MCP servers, long system prompts, or compacted sessions. Plain Agent dispatch under Opus 4.8 is enough to reproduce.

Still reproducing on the latest CLI (v2.1.181) with Opus 4.8 (1M context).

• The malformed turn is consistently one where a tool call is emitted immediately after prose text (notably non-English / Japanese). Emitting the tool call as the first block of the turn, with no preceding prose, succeeds reliably.
• /compact makes no difference, which is consistent with a server-side model serialization problem rather than client-side context bloat.
• So far the only reliable mitigation is switching the model off Opus 4.8 (to 4.7 / Sonnet).

Confirming this is NOT fixed as of v2.1.181.

Follow-up from Japan (JUN-WEBLISS, same reporter as the 2026-06-14 comment above). Adding a fresh data point where 4.8 broke a concrete real-world workflow, and a workaround pattern that survived it.

Environment

• Model on the main loop: claude-opus-4-8 (via /model opus[1m], 1M context)
• Claude Code: VS Code extension (Windows 11, Japanese locale, ja-JP)
• Session period: 2026-07-12 13:28 – 16:00 UTC (~2.5 h)
• Task: a design "style-harvesting" harness that scrapes several public sites' rendered CSS and asks the model to extract layout archetypes with real measured values

What broke

Across 133 assistant turns (all message.model == "claude-opus-4-8" in the transcript), the harness rejected two turns outright with

Your tool call was malformed and could not be parsed. Please retry.

at 2026-07-12T15:18:13Z and 2026-07-12T15:39:48Z.

Two rejections in 133 turns sounds small, but they landed on the orchestration steps of a parallel-Workflow that was fanning tool calls out to multiple Sonnet subagents. Each malformed turn corrupted the batched dispatch, and the run ended before the tool-heavy extraction stage had a chance to reach measured values. The outputs it did produce were "candidate-only, unverified" — plausible-looking summaries without evidence-grounded values behind them. A later verification pass flagged material issues in that output. So this isn't just a retry-cost problem — the run can close successfully while quietly producing content that a downstream check would reject.

This is a different failure mode from the "assistant goes silent" one described in the original report and by @hiroyuki-togo / @mtskf: here the surface behaviour was "the task completed", but the outputs were shaped by degraded orchestration under repeated malformed retries.

What worked as a workaround

We rebuilt the same style-harvesting task with:

• main loop: Opus 4.8 (still), used only for instructions and final judgment
• fan-out: a Workflow with 3 parallel Sonnet 5 subagents doing the actual tool-heavy CSS extraction

The re-run completed in 9.6 min with 0 errors, and adversarial verification against the raw scraped HTML passed on every extracted value. Empirically it looks like the Opus 4.8 tool_use malformation is proportional to how much of the tool-calling work the 4.8 model itself is doing; pushing tool-heavy work down to Sonnet subagents made the orchestrator's own malformed rate low enough to not corrupt the run.

After confirming this pattern we rolled the main loop back to claude-opus-4-7 (stable). Current session shows 13/13 assistant turns on claude-opus-4-7 and no malformed events. So the mitigation on our side is the same one @Neige-Neige documented at the top of this thread: 4.7 is still the safe default for tool-heavy sessions, more than a month after this issue was opened.

Two things I'd flag for whoever is looking at this

1. The failure isn't always visible as an interrupted turn. In a multi-agent Workflow, a small malformed rate on the orchestrator is enough to produce a successful-looking run with substantively wrong content downstream. Any evaluation that only counts "user-visible retries" will under-report the impact.
2. Same shape as @mtskf's 2026-06-27 observation: the malformed turns in our transcript are ones where a tool_use block follows Japanese prose in the same response. Emitting the tool_use as the first block of the turn (no preceding prose) is what we now do defensively in prompts, and it does reduce the rate.

Happy to share the parsed transcript slice (redacted) if it helps.