claude-code - 💡(How to fix) Fix [Bug] Tool-call markup leaks into assistant text instead of tool_use block causing silent no-op

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

  1. Confirm whether stop_reason:"tool_use" without a tool_use block is surfaced as an error anywhere (currently silent).

Code Example

[]
RAW_BUFFERClick to expand / collapse

Bug Description Title: Raw tool-call markup (call + <invoke>) leaks into assistant TEXT instead of a tool_use block → silent tool no-op

Env: Claude Code 2.1.158 / Opus 4.8 1M (claude-opus-4-8[1m]) / launch: claude --dangerously-load-development-channels server:claude-peers / effort: ultracode/xhigh / macOS arm64 (Darwin 24.6.0)

Summary: In a long-running session, the tool-call wrapper markup (literal token call followed by <invoke name="...">) was emitted/persisted as assistant TEXT instead of being parsed into a structured tool_use block. When this happens the tool does NOT execute — a silent no-op seen by the operator as "the action didn't run."

Evidence (parsed from persisted transcript JSONL), session f13f67c9-5580-4dc0-9b3d-fac4f2bddc99:

  • 40 assistant messages contain raw call\n<invoke ...> inside message.content[].text
  • 10 of them have stop_reason:"tool_use" but NO tool_use block in content → confirmed silent no-op
  • Tool breakdown of 44 leaked <invoke>: Bash 24 / mcp__claude* 14 / Read 2 / Edit 2 / Write 1 / ToolSearch 1 → tool-agnostic
  • Fresh sessions show 0 occurrences (checked 5) → per-session degeneration / streaming-parser boundary, not deterministic input
  • Not user config: CLAUDE.md / .claude/rules contain no call/invoke directives

Impact: peer messages, PR merges, deploys, file ops can appear issued but never execute. Operator sees "nothing happened"; only recoverable by retry.

Requests:

  1. Investigate the streaming parser / tool-call repair / transcript serialization boundary that lets raw tool markup land in text.
  2. Add a client-side guard: if raw <invoke> markup appears in a text stream, reject/retry instead of display+persist as no-op.
  3. Confirm whether stop_reason:"tool_use" without a tool_use block is surfaced as an error anywhere (currently silent).

Transcript attachable: session id f13f67c9-5580-4dc0-9b3d-fac4f2bddc99


Environment Info

  • Platform: darwin
  • Terminal: WarpTerminal
  • Version: 2.1.158
  • Feedback ID: 40f927ba-fa83-44a6-9b3f-6a91d551877a

Errors

[]

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] Tool-call markup leaks into assistant text instead of tool_use block causing silent no-op