Tool calls intermittently fail with "malformed and could not be parsed"; markup rendered as chat text

Bug: Tool calls intermittently fail with "malformed and could not be parsed"; tool-call markup is rendered as chat text

Environment

• Claude Code version: 2.1.169
• OS: macOS (Darwin 25.5.0)
• Model: Opus 4.8 (1M context) — claude-opus-4-8[1m]
• Setup: multiple concurrent sessions / git worktrees

Description

During sessions, tool invocations (Bash / Edit / Read, etc.) intermittently fail with:

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

When this happens, the tool-call markup is rendered into the visible chat transcript as plain text instead of being executed — e.g. the user sees <invoke name="Bash">...</invoke> literally in the output.

Suspected root cause

The correct tool-call markers carry a namespace prefix (antml:invoke / antml:parameter). The failure appears to occur when the markup is emitted without that prefix (bare <invoke> / <parameter>), so the parser does not recognize it as a tool call and falls back to rendering it as text.

Reproduction

• Not tied to a specific tool — observed with Bash and Edit
• Intermittent within a single session (success and failure interleave)
• Reproduces across multiple separate consoles/sessions, which suggests a structural parser behavior rather than per-session context corruption
• Once it occurs, the malformed output remaining in context appears to increase the chance of recurrence on subsequent tool calls (the model references its own prior malformed shape)

Distinguishing from a related symptom

• This bug: the markup reaches the parser and is rendered as text (parser sees it but does not recognize it)
• Different symptom (not this report): tools that silently never start — no text, no execution
• Not a permission denial (no denied message is shown)

Impact

• At least one extra round-trip per occurrence (notice → re-issue with correct markup)
• Forces the user to re-prompt ("continue")
• When it occurs immediately before an irreversible action (posting a comment, pushing), the re-issue raises the risk of targeting the wrong object

Current workaround

1. On noticing the malformed output, re-issue the call with correct namespaced tags — re-issuing reliably succeeds
2. Restart the session only if 3 consecutive re-issues fail (after confirming any GitHub/state saves landed)

Expected behavior

• On a malformed tool-call emission, the parser should either recover from a missing namespace prefix, or
• Not render the failed markup as transcript text — instead auto-retry or surface an explicit error

Notes

This report itself was produced in a session where the bug recurred several times — including on the very commands used to file it — so the session transcript is a live reproduction log.