Table of Contents
- 1. What is actually happening — the "court" token and invoke tags
- 2. Background: an agent "generates" its tool calls too
- 3. Why it happens — two root causes and triggers
- 4. Three common misconceptions, corrected
- 5. Fix it now (for Claude Code users)
- 6. For developers: prevent it via the API/SDK
- 7. Telling it apart from similar errors
- 8. Official status
- 9. Prevention checklist
- Summary
- FAQ
If you have run long sessions in Claude Code, you may have seen a strange string suddenly stream into your screen:
court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…description of the command…</parameter>
</invoke>
Your tool call was malformed and could not be parsed. Please retry.A tool call (a command) that was supposed to run behind the scenes leaks into the chat as raw text — and never executes. At the front sits a meaningless word, court (or call). It is natural to worry "did my machine break?" or "did I misconfigure something?" But the short answer is: this is not your environment, and not your command.
It is a model-side glitch in which Claude (especially the Opus 4.8 / 4.7 family) corrupts the "control tags" of a tool call at the moment it generates them. Anthropic's official repository has many open issues about it (#64108, #64150, #64690, #65705, #66153, #67295, #68354, and more). This article lays out the mechanism, causes, common misconceptions, user/developer fixes, how to distinguish it from similar errors, and the official status — grounded in Anthropic's docs and the actual issues. The single most important move, up front: when court appears, do not grind away in that session — bail out to a fresh session (/clear) early. The reason is explained below.
What "court" + leaked invoke tags really are
— a control tag is generated broken, so it leaks to the screen instead of executing
A broken call cannot be parsed, so it is never executed (fail-closed) — there is no risk of a wrong command running.
The real problems are a wasted turn, and a "chain reaction" if you leave it unchecked.
1. What is actually happening — the "court" token and invoke tags
The <invoke name="Bash"> and <parameter name="command"> you see are "tool-call markup" that you are never supposed to see. When Claude runs a command or edits a file, it generates these XML-style structured tags as tokens, and Claude Code (the harness) parses them and actually runs the command. Normally the harness absorbs the tags, they never reach the screen, and you only see the result of the tool.
This time, however, the "opening control token" of the tool call was generated broken, with the unrelated word court or call creeping in at the front. The harness only reacts to strict syntax, so it decides "this is not a tool call, just text" and streams it straight to the screen. The command does not run, and you get "Your tool call was malformed and could not be parsed." In some cases there is no error message at all and it simply stalls in silence (in issue #65705 the response came back as stop_reason=end_turn with nothing to execute, so the conversation hung).
The word court itself has no meaning. But it is not a fully random, one-off word either — across multiple independent reports, the leak shows up as court / call with uncanny consistency. Issue #64690 analyzes it as "a token adjacent in the vocabulary being selected instead of the correct tag." In other words, court is best understood as a signature that helps you recognize this bug.
2. Background: an agent "generates" its tool calls too
Why can a "control tag" break at all? The key is that for an AI agent, a tool call is ultimately just text generation.
When you use tools with the Claude API, the format you see as a developer is JSON (a tool_use block). Internally, however, the model follows a hidden system prompt that Anthropic injects automatically and generates the wrapping tags <function_calls>, <invoke>, and <parameter> as a stream of tokens. The API layer then parses these and converts them into a clean tool_use JSON block (per the official tool-use docs). Every "tool call" in MCP and AI agents rides on top of this mechanism.
What matters here is that the harness parser is "fail-closed" (it errs on the safe side). If a tag differs from the expected form by even one token, the harness does not guess and run it — it immediately rejects it as malformed. This is the right harness design: "helpfully fixing up" an ambiguous command and running it would be far more dangerous. So this whole phenomenon is a case of "broke → got rejected → did not run" — in other words, it failed safe.
In one sentence
A tool call is "text with special tags" that the model generates. When the opening token of those tags breaks during generation, the harness cannot recognize it, so it leaks into prose and does not run. The rejection itself is a correct safety mechanism; the bug lies purely in the model-side generation.
3. Why it happens — two root causes and triggers
Consolidating the real issues, the cause splits into "(1) corruption at generation time" and the "(2) chain reaction from self-poisoning" that makes it nasty.
How it breaks, and then "chains"
· Multiple tool calls in one message / a tool call placed right after prose (#66153)
· The state right after running
/compact (#67295: recurs on the first call after compact)· Background Bash (run_in_background) or 3+ connected MCP servers (#64690)
· Paragraph-length long tool arguments (#49747: a separate variant where XML bleeds into JSON)
Takeaway: the breakage itself is rare sampling jitter. The truly nasty part is the chain in (2) —
which is why "grinding away with retries in the same session" can be the worst move.
4. Three common misconceptions, corrected
Information about this phenomenon gets muddled easily. To respond correctly, here are three common misconceptions set straight.
| Common belief | Reality |
|---|---|
| "The tool went rogue / malfunctioned" | The opposite. The broken call was rejected without executing (fail-closed). There is no risk of a wrong command running; all that happened was a "wasted turn + a visual leak." It failed safe. |
| "Just retry — it self-heals if you leave it" | Only half true. A mild case recovers on one retry, but once the broken block sits in history the model imitates it and chains. #65705 saw 14 failures in a row over 5+ hours; #66153 saw 30+ in one session. Grinding in the same session backfires. |
"court means something / is a command" | It means nothing — just debris from a corrupted control token. But court/call recur as a marker, so they are useful as a diagnostic sign. |
The second one matters most. Incident reports often say "it recovered on retry, so no problem" — but that only holds for the "mild" case before the chain begins. The essence of this bug is that once it enters chain mode, no amount of retrying within that session will fix it.
5. Fix it now (for Claude Code users)
The response depends on "are you still mild, or has the chain started?" In priority order:
Order of priority
court appears, /clear or start a new session early. Cutting the poisoned history is the most reliable. Before moving, save state with git commit or a handoff note./compact has been reported to recur right after — it is not a reliable fix.
The rule: "miss twice, abandon the session and start fresh."
The longer you grind in poisoned history, the deeper the wound. Keep the CLI current (but note: no fix has shipped yet — updating is hygiene, not a magic cure).
Tip: if you routinely save state to git or a .md handoff note, moving to a new session at any moment costs you nothing. The more you run long autonomous sessions, the more this habit pays off (and it ties directly into managing your context window).
6. For developers: prevent it via the API/SDK
If you build your own agent on the Claude API / SDK, you can add the following defenses in your harness. The detection logic proposed in issue #65705 is practical.
// Inspect the received assistant turn before executing
const text = assistantText(resp);
const looksLeaked =
/<invoke\s+name=/.test(text) ||
/function_calls/.test(text) ||
/\bcourt\s*<invoke/.test(text);
// 1) Above markup present but NO structured tool_use block → broken call
if (looksLeaked && !hasToolUseBlock(resp)) {
// 2) Do not show it; log it. Do NOT keep the broken block in history (prevents self-poisoning)
// 3) Nudge "emit it as a structured tool_use, not text" and auto-retry
return retryWithNudge(messages);
}
// Reject an incomplete tool_use caused by truncation
if (resp.stop_reason === 'max_tokens' && lastBlock(resp)?.type === 'tool_use') {
return retryWith({ max_tokens: higher }); // do not execute
}Four principles. (1) Always check stop_reason (an end_turn with no tool actually running = detect the silent stall). (2) Before executing, verify the text does not contain <invoke name= or function_calls; if it does, retry instead of executing. (3) Do not keep the broken block in the conversation history (keeping it makes the next generation imitate it — self-poisoning / #62344). (4) Keep tool arguments short and split long output (avoid the long-payload variant in #49747). Even when using an official harness like the Claude Agent SDK, it is worth understanding how long-running loops behave.
7. Telling it apart from similar errors
There are several "the tool will not run" errors, and they need different fixes. Distinguish these four so you do not confuse them.
| Symptom | What it really is | Main fix |
|---|---|---|
| court / call + raw invoke tags shown, not executed | This article's topic. Control-token generation corruption + chaining via self-poisoning | Prefer a fresh session (/clear); do not grind after two misses |
| 400 "thinking blocks cannot be modified" locks the session | A signature mismatch in extended thinking (a different bug). An API hard error | See the dedicated article (Esc×2 / rewind) |
| The response is cut off mid-stream (no garbled XML) | A normal truncation from hitting max_tokens. Not an error | Raise max_tokens and re-run |
| XML is not structured on Bedrock, LangChain, etc. | A third-party client failing to parse Anthropic's format (langchain-aws #521). Does not reproduce on the official API / Claude Code | Revisit the integration library / hosting layer |
The axis for telling them apart is simple. If you see a "court / call garble + raw XML," it is this bug. A 400 signature error is the thinking-block error. A clean cutoff is just the output limit. Only on Bedrock or via LangChain points to the integration layer. For other common Claude Code errors, see the error roundup.
8. Official status
As of June 2026, there is no confirmed official fix (changelog entry) that says this phenomenon has been resolved. Tracing the release notes up through the latest Claude Code (the 2.1.183 line), there is no entry addressing tool-call serialization corruption, and many of the related issues remain open, or are filed as "duplicate / stale." So every fix in this article is a workaround while awaiting an official fix, and you cannot claim "updating to the latest version fixes it" (updating is recommended, but it is not a guaranteed cure).
That said, the fail-closed harness design of "reject a broken call rather than guess-execute it" is itself correct. What needs fixing is the model's generation stability — not loosening the parser to "fix it up and run it anyway," which would invite the serious risk of running the wrong command. The best thing we as users can do is operate to avoid the chain, and report reproductions to the official issues with your environment and logs (more reports raise the priority and speed up the fix).
9. Prevention checklist
Claude Code users: (1) When court/call appears, retry at most twice; if it persists, /clear / new session immediately. (2) Avoid very long / multi-day sessions; save work to git/notes at breakpoints. (3) Do not cram multiple tool calls into one message. (4) Remember that /compact is not a cure-all (it can recur right after). (5) Keep the CLI current, and report reproductions to the official issues.
API/SDK developers: (1) Always check stop_reason. (2) Detect <invoke name= / function_calls leaking into text and retry. (3) Do not keep broken calls in history (prevent self-poisoning). (4) Keep tool arguments short; split long output. (5) Never execute an incomplete tool_use from a max_tokens cutoff — retry instead.
Summary
In Claude Code, "court / call + a raw <invoke> tag shown, with the tool not executing" is a model-side glitch in which Claude (the Opus 4.8 / 4.7 family) generates the control token of a tool call in a broken form. The harness rejects it fail-closed, so there is no risk of a wrong command running (it failed safe). The truly nasty part is that once the broken block stays in history, the model imitates it and "chains." So "retrying fixes it" only holds while mild, and the rule becomes "miss twice, bail to a fresh session."
The cause is two-layered: (1) control-token generation corruption + (2) chaining via self-poisoning. Triggers include long / multi-day sessions, heavy context, the post-/compact state, multiple concurrent tools, 3+ MCP servers, and long tool arguments. Since no official fix has shipped as of June 2026, every remedy is a workaround. Users should "prefer a fresh session + save state often"; developers should "check stop_reason, retry on leak detection, never keep broken history, and shorten arguments." Reading the thinking-block 400 error, the Claude Code error roundup, and MCP alongside this will make you far more resilient to tool-call trouble.
FAQ
Q. Is the "court" or invoke tag on my screen caused by a mistake in my command or settings?
A. No — almost certainly not. This is a known model-side glitch where Claude generates tool-call tags in a broken form, with several issues filed in Anthropic's official repository (#64108, #65705, #66153, and more). It is not a mistake in your environment, command, or settings. Treat court/call as a "signature" of the bug.
Q. Could a wrong command run and damage my server or files when this happens?
A. No. A broken tool call is judged "malformed" and rejected without executing (fail-closed design). All that happens is that the turn is wasted and the control text becomes visible; there is no effect on your data or server state. It is designed to fail safe.
Q. I heard "just retry and it fixes itself." Is that true?
A. Only when it is mild. On a first, one-off occurrence, a nudge to "continue" often makes it re-emit correctly. But once the broken block stays in the conversation history, the model uses it as a template and repeats the same corruption (self-poisoning). At that point retrying in the same session backfires. If it fails twice in a row, stop grinding and move to a fresh session (/clear).
Q. Will /compact fix it?
A. Not reliably. Compacting the context sometimes helps, but in issue #67295 it recurred on the very first tool call right after /compact. The most reliable move is not /compact but a fresh session (/clear) that fully resets the history. Save your work state to git or notes before you move.
Q. Will updating Claude Code to the latest version fix it?
A. You cannot say it "fixes" it. As of June 2026 there is no official changelog entry confirming a fix, and many related issues remain open or duplicate. Updating is recommended as hygiene, but it is not a magic cure. For now the best approach is operating to avoid the chain (miss twice → fresh session) and reporting reproductions to the official issues.
