[Bug] Desktop app (Code tab) 1.9659.4: Opus 4.8 "tool call could not be parsed (retry also failed)" still reproduces

Summary

On the Claude Desktop app (Code tab) version 1.9659.4, the Opus 4.8 model frequently fails a turn with:

Turn failed — Try sending your message again. The model's tool call could not be parsed (retry also failed).

The turn appears to think for a while and then dies; the action is silently dropped. This makes longer agentic sessions on Opus 4.8 unreliable.

I'm filing this specifically from the Desktop GUI (Code tab), since most existing reports are from the CLI. Confirming it still reproduces on desktop build 1.9659.4 (latest at time of filing).

Environment

• Surface: Claude Desktop app → Code tab (not the CLI)
• Desktop app version: 1.9659.4
• OS: macOS
• Model: claude-opus-4-8 (default Opus). The error is strongly correlated with Opus 4.8 — it does not appear when I switch the same workflow to Opus 4.7 / Sonnet 4.6.
• Workflow: sessions typically involve mixed Chinese (CJK) text + code (Edit/Write/Bash with multi-line CJK + code arguments).

Symptom

• Intermittent but frequent. A turn that should issue a tool call instead ends with the harness error above.
• Automatic retry resends the same context and also fails → retry also failed, and the turn is aborted.
• Switching the same session/workflow to Opus 4.7 or Sonnet 4.6 → the error stops. This points to an Opus-4.8-side regression, not a desktop-shell issue (and indeed a desktop app version bump alone does not fix it).

Note on the desktop version

There is no public per-build changelog for the desktop app, so I can't tell from release notes whether 1.9659.4 was supposed to address this. Empirically it does not fix the problem — the error still reproduces on this build.

Related / likely-duplicate issues

This is the same underlying failure mode described in (linking so maintainers can consolidate the desktop data point):

• #64506 — parsing fails with long multibyte / CJK string arguments
• #64418 — Opus 4.8: tool calls serialized as plain text instead of tool_use blocks
• #64235 — regression since 2026-05-29: tool_use block absent on a stop_reason=tool_use turn
• #64176 — version bisection of the regression (2.1.150–2.1.158)
• #63687 — Opus 4.8 (1M): frequent malformed tool_use despite tools executing
• #64375 — frequent tool execution errors with Opus 4.8

Root cause as analyzed in those threads: on a stop_reason: tool_use turn, the model serializes the call as legacy <invoke> XML text (sometimes with a stray court/count token, or a dropped antml: prefix) instead of a structured tool_use block, so the parser fails; the single retry replays identical context and fails again.

Workaround (for other affected users)

• Switch the model away from Opus 4.8 → Opus 4.7 or Sonnet 4.6.
• Start a fresh session instead of resuming a session that already contains a malformed turn (the malformation self-reinforces on replay).

Suggested client-side mitigations

1. On the malformed-tool-use retry, don't resend the just-failed assistant turn verbatim (or strip the leaked <invoke> text first), so the retry has a chance to differ.
2. Treat stop_reason: tool_use + 0 tool_use content blocks as a signal to fall back to parsing the <invoke name="..."> markup out of the text block, or at least drop it before persisting so resume doesn't re-poison the session.