claude-code - 💡(How to fix) Fix Tool calls emitted as literal <invoke> text instead of executing, in long tool-heavy sessions (Opus 4.7 1M tier)

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…

In long, tool-heavy sessions on the Opus 4.7 1M-context tier, Claude Code intermittently emits a tool call as literal text (the <invoke name="..."> / <parameter> markup, sometimes prefixed with a stray word like count) in the assistant's response instead of executing a structured tool call. The command never runs, so the session appears frozen while the assistant otherwise looks like it responded normally.

Root Cause

Severity

A session can silently stall for an extended period before a human notices, because the assistant appears to be responding normally — the only signal is that nothing actually executes.

RAW_BUFFERClick to expand / collapse

Summary

In long, tool-heavy sessions on the Opus 4.7 1M-context tier, Claude Code intermittently emits a tool call as literal text (the <invoke name="..."> / <parameter> markup, sometimes prefixed with a stray word like count) in the assistant's response instead of executing a structured tool call. The command never runs, so the session appears frozen while the assistant otherwise looks like it responded normally.

Environment

  • Claude Code 2.1.146
  • Model: claude-opus-4-7[1m] (1M extended-context tier), effort medium
  • macOS (Apple Silicon), Terminal, --remote-control wrapper sessions

Symptom

The assistant message contains the raw tool-use markup as visible text. No tool executes. In the iPhone app the transcript shows the <invoke> / <parameter> block rendered as plain text.

Trigger

Appears after a session accumulates large context (observed ~500K+ tokens) with sustained tool use. Two independent sessions hit it on the same day once their context was large; a fresh/short session does not exhibit it.

Self-reinforcing

Once one tool call leaks as text, the assistant keeps mimicking the textual form on subsequent turns (the leaked markup sits in context as a pattern it continues). Single corrective nudges recover it only transiently before it recurs.

What does NOT fix it

Restarting the process with --resume does not fix it — the same (contaminated) context reloads and the glitch recurs immediately on the next tool call.

What DOES fix it

/compact reliably fixes it — the summary replaces the verbatim leaked-markup turns, removing the pattern the model was mimicking. Caveat observed: /compact must be issued at an idle prompt; if sent while the session is busy it is queued rather than executed.

Related (different backends, same class of failure)

  • jundot/omlx#159 — emits literal [Tool call: ...] text / stalls under long prompts (Anthropic /v1/messages + MCP)
  • ollama/ollama#15529 — prints raw JSON instead of executing tool calls

Severity

A session can silently stall for an extended period before a human notices, because the assistant appears to be responding normally — the only signal is that nothing actually executes.

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 Tool calls emitted as literal <invoke> text instead of executing, in long tool-heavy sessions (Opus 4.7 1M tier)