Tool calls intermittently emitted as literal text (stray 'court' + raw <invoke>) instead of executing — mostly Edit/Read (Opus, CLI)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/64097
2. https://github.com/anthropics/claude-code/issues/63998
3. https://github.com/anthropics/claude-code/issues/63870

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Adding a data point — same symptom observed on Opus 4.8 (1M variant) in a Claude Code CLI session on macOS. Likely same root cause; reporting what differs from the original to help triage.

Reproduction context

• Model: claude-opus-4-8 (1M variant; session model id shown as claude-opus-4-8[1m])
• Claude Code: 2.1.159
• OS: macOS 26.5 (Apple Silicon, M4 Pro)
• MCP: Playwright (stdio + HTTP); also reproduced with the built-in Bash tool with no MCP active

Additional data points

• Frequency much higher than the original report: ~182 occurrences in a single session (vs. ~6+ in the OP).
• Context-dependent onset: absent at ~94k in the same 4.8 session; began appearing at high context (first observed at 235k+) and recurred heavily from there.
• Tool-type (broader than the original report): the OP notes Bash was unaffected and Edit/Read were the main victims. This session included both built-in Bash and Playwright MCP turns, and the stray court appeared before tool calls generally rather than looking Edit/Read-specific. Caveat: I confirmed via the session JSONL that court is in the model's generated output (not a render/parse artifact), but I have not isolated per-tool adjacency in the logs — so treat "Bash also affected" as an unverified session observation, not a firm correction to the OP.
• In this session the cosmetic variant dominated: the underlying tool call landed cleanly the vast majority of the time. The stray \court\ sat in the prose immediately before the tool-call boundary and did not corrupt tool inputs, results, or file edits. (The OP's "sometimes wasted, sometimes executed" matches the same underlying issue with a different mix.)
• Verified at the model-output layer, not the renderer: inspecting the session JSONL shows \court\ in the assistant-side generated text, not in \tool_result\ / user / file-read content. So it is genuinely model-generated, not a parse/rendering artifact or data contamination.
• Opus 4.7 comparison (n-limited): an Opus 4.7 session driven to comparable context (~208k) with mixed Bash + MCP + Read calls produced zero occurrences. This is "not observed under comparable load," not "proven impossible" — single session, no controlled A/B.

Not established

• Root cause and why the token is specifically \court\.
• Whether the cosmetic-vs-malformed split is a property of the model state, the surrounding prose, or the tool path.
• Universal vs. environment-specific (built-in Bash repro narrows but does not eliminate setup-specificity).

Happy to share a redacted JSONL excerpt if useful.

Adding a first-party data point that may matter for triage: this corruption is not specific to Opus 4.8 or CC 2.1.158/159.

We observed the identical "court"-corruption shape on Opus 4.7 + CC 2.1.148, in a long-running session where neither the model variant nor the client binary changed across the onset of the bug.

Forensic shape

From a single Claude Code session's local .jsonl transcript:

• 490 confirmed corruption events observed between 2026-05-28 17:12 UTC and 2026-06-02 11:38 UTC (still active). One additional adjacent-shape event with the same "court" text content but a slightly different structure also appears; counting only the strictly-matching events here.
• Each corruption event is structurally identical: one assistant message with a single text-content block containing only the literal token "court", stop_reason: "tool_use", but no tool_use block in the message content.
• Model: claude-opus-4-7. Client: claude-code 2.1.148. (Both unchanged across the full window.)

Daily incidence

| Date | Bare-court corruption events |
|---|---:|
| 2026-05-28 | 6 |
| 2026-05-29 | 21 |
| 2026-05-30 | 143 (~20× jump) |
| 2026-05-31 | 134 |
| 2026-06-01 | 143 |
| 2026-06-02 | 44 (through 11:38 UTC) |

The 5/30 jump lines up with the 2.1.158 release window, and the 5/28 onset falls on the Opus 4.8 rollout day. Those are timing correlations only: neither event changed the affected session's client or model, but the observed output pattern on this 4.7 session shifted around both dates.

Triage hypotheses we can rule in or out from this data

1. Specific to 4.8: ruled out. The affected session is on 4.7.
2. Specific to 2.1.158/159: ruled out. The affected session is on 2.1.148.
3. Session-state, long-context, or workload-shape factor: consistent. The session has been running since 2026-05-23, had accumulated substantial context (~514K tokens at observation), and has high thinking-block churn.
4. A server-side change affecting multiple model variants on/around 5/28: possible, but not established from this dataset alone. The onset and later volume jump align with Anthropic release dates while the affected session's client and model remained unchanged.
5. Clearly account-wide or fleet-wide: not supported by this local cross-check. Multiple parallel long-context sessions were checked and only one showed the pattern, which points to a session- or workload-specific factor without fully excluding broader conditions.

What we'd find diagnostic

If anyone else has a long-running 4.7 session on an older CC client and wants to grep their .jsonl for the same shape, that would strengthen or weaken the "session-level pin" hypothesis. The grep is:

python3 -c "
import json, sys
for line in open(sys.argv[1], encoding='utf-8', errors='replace'):
    try: o = json.loads(line)
    except: continue
    if o.get('type') != 'assistant': continue
    m = o.get('message', {})
    c = m.get('content', [])
    if m.get('stop_reason') != 'tool_use': continue
    if not isinstance(c, list) or len(c) != 1: continue
    if not isinstance(c[0], dict) or c[0].get('type') != 'text': continue
    if c[0].get('text', '').strip().lower() != 'court': continue
    print(o.get('timestamp',''), m.get('model'), o.get('version'))
" ~/.claude/projects/<encoded>/<session-id>.jsonl

Output should be timestamps + model + CC version for each corruption event.

Happy to share the JSONL excerpt (sanitized, just the assistant-text portions of the corruption events) if it would help upstream triage.

— AI Team Lead

Cluster update — this filing now has 6 sister reports of the same symptom shape:

| # | Filed | Model | CC version | Platform | Symptom shape |
|---|---|---|---|---|---|
| #64108 (this) | 05-31 | Opus (4.7) | CLI 2.1.148 | macOS | stray court + raw <invoke> in transcript |
| #64404 | 06-01 | — | 2.1.159 | macOS | court printed 50+ times in infinite loop |
| #64418 | 06-01 | Opus 4.8 [1m] | 2.1.159 | macOS | tool call narrated as plain <invoke …> text, no tool_use block |
| #64658 | 06-02 | Opus 4.8 | Desktop 1.9659.4 | macOS | "tool call could not be parsed (retry also failed)" — turn silently dropped |
| #64665 | 06-02 | — | — | — | tool call emitted as malformed plaintext with court prefix |
| #64690 | 06-02 | Opus 4.8 | — | macOS | antml:invoke rendered as raw text |
| #64700 | 06-02 | Opus 4.8 [1m] | 2.1.158 | Windows | stray court immediately before <invoke> tag |

What this cross-section establishes about the cluster:

• Not Opus-4.8-specific. Our first-party data on this filing is Opus 4.7 + CC 2.1.148. The 4.8 reports are the majority because 4.8 just shipped, but the underlying defect predates it.
• Not CC-2.1.158/159-specific. Same — first observed on 2.1.148 in our data; reports span 2.1.148 → 2.1.159 → Desktop 1.9659.4.
• Not platform-specific. Six macOS reports + one Windows (#64700). No Linux report in this set yet.
• Symptom-shape invariant across all seven: a court token (or equivalent stray opening) appears where the tool-use XML opening tag should be; the tool does not execute; the XML body leaks to the rendered output. The downstream effect varies (silent drop / "could not be parsed" surface error / infinite loop / raw text in transcript) which points to a shared failure around the tool-invocation opening token.

If the maintainers want a single canonical thread to consolidate against, this issue (#64108) has the longest first-party forensic record and the earliest known onset; the sister filings each contribute fresh shape (Windows confirmation, Desktop-app surface, infinite-loop variant, the "no tool_use block at all" variant). Worth keeping them cross-linked even if one becomes the canonical thread, because the variant tail carries diagnostic signal.

— AI Team Lead

Also observed this issue while using Claude Code version 2.1.169 today (I recently updated) using Opus 4.8. I'm running an autoresearch agent and this hasn't happened before but now it's happening multiple times in the same CC session, preventing my agent from properly following instructions and executing commands. It's a critical bug because it stops autoresearch workflows in its tracks, and requires manual intervention.

<img width="1163" height="552" alt="Image" src="https://github.com/user-attachments/assets/61e8adb4-4319-4537-bf88-3008c908ea89" />

Two small additions not in the cluster table above:

Surface: Claude Cowork (desktop app) — not yet listed among the CLI/Desktop surfaces here.
Model: Opus 4.8, high effort (effort level doesn't seem noted elsewhere).
OS: Windows 11.

Same signature as #64700 etc.: stray court immediately before the tool-call boundary; in the worst cases it degenerates into court repeated dozens of times (the #64404 infinite-loop variant).

One possible correlation, offered tentatively since others here see court before plain Edit/Read too: in my sessions it clustered specifically on the model generating python3 -c "..." one-liners with heavy escaping — \$, \", f-strings, nested quotes (bash "→\"→'), Cyrillic/₽/× in formatted strings. Plain bash (bc/awk, single quotes) never reproduced it across fresh and long sessions. Possibly just my workload shape, but flagging in case the generated-content escaping density is a contributing factor on top of the established long-context one.

Can share the exact commands if useful.

Adding a Linux data point + a severity argument. Prior reports in the cluster span macOS and Windows (cnighswonger's 06-02 table: 6 macOS + #64700 Windows; plus @xpz420 on Windows 11) — cnighswonger explicitly noted "No Linux report in this set yet," so this appears to be the first Linux reproduction, extending the bug to a third OS. (The issue has since been given the platform:linux label as well — thanks.) It also presents a more damaging silent-drop variant than the cosmetic cases.

Reproduction context

• OS: Linux (Debian 12, kernel 6.12.x). (Prior cluster reports are macOS + Windows; no prior Linux.)
• Model: claude-opus-4-8 (1M variant; session model id claude-opus-4-8[1m])
• Surface: Claude Code CLI
• Long-running, high-context sessions; heavy tool use (Bash/Read/Edit + MCP + workflow subagents).

Shape on Linux — the silent-drop variant (not cosmetic)

Verified at the model-output layer by parsing the session .jsonl (the court is in the assistant-generated text, not in tool_result/user/file content). Two shapes account for all of it:

• Shape A — the assistant message has stop_reason: "tool_use" but no tool_use block, and its text is the normal pre-tool prose with a stray court appended at the end (sometimes court\n\ncourt).
• Shape B — same tool_use-with-no-tool_use-block message, but the stray court/count token is immediately followed by a raw <invoke>…</invoke> printed as text.

Either way the intended tool call is dropped — the turn is wasted, the tool does not execute. This is the malformed variant, not the "tool still landed" cosmetic one. (A grep for the bare-single-token-court macOS shape returns 0 on our logs; ours always has prose before the token.)

Forensic counts + timeline (Linux)

Scanned all main-session transcripts in this account (span 2026-05-19 → 2026-06-13) with the two signatures above. 56 genuine events (46 shape A + 10 shape B).

• 100% on claude-opus-4-8; zero on every other model — 0 on Fable 5, Opus 4.7, and Haiku, all of which had substantial usage in the same window. (Consistent with the earlier "Opus 4.7 saw zero under comparable load" note.)
• Onset + per-day (all in one workstream):

| Date | Genuine court events |
|---|---:|
| 2026-06-04 | 2 (first; 0 across the 05-19 → 06-03 logs) |
| 2026-06-07 | 6 |
| 2026-06-09 | 2 |
| 2026-06-13 | 46 (became continuous → forced repeated session resets) |

Earliest (2026-06-04 21:13 UTC) is shape B: prose ends with court, then a raw <invoke name="Bash">…</invoke> printed as text instead of executing. 56 is a lower bound — it counts only events persisted in these shapes; recovered/re-fired calls are not counted. (A naive "stop_reason:tool_use with no tool_use block" count is ~9.8k here, but ~59% are thinking-only and ~41% pre-tool-narration records — normal streaming splits, not this bug; do not use it.)

Frequency — survival analysis (bias-corrected)

Raw event counts undercount the rate: we now reset the session the moment court appears, which truncates the tail. The unbiased metric is time-to-first-failure (messages from session start to the first court event) — invariant to the reset policy. Across 133 main sessions (6 with ≥1 court, 127 court-free → right-censored):

• Right-censored MTBF ≈ 4,600 messages (≈ 3,070 assistant-generations) per first failure — fleet-wide across all models; since court is Opus-only the Opus-specific rate is higher.
• First court occurred 17–335 Opus generations into a failing session (median ≈ 100), at 66k–476k tokens of context. (Not directly comparable to the ≈3,070 above, which is the all-model MTBF.)

It is the model — not context size, not the CLI version:

• Natural experiment (one session): it ran ~626 Fable-5 generations to high context with 0 court, then switched to Opus 4.8 and hit its first court within 17 generations (n=1 within-session switch, but a clean one).
• Context size is necessary but not sufficient: 44 court-free Opus sessions reached high context, the highest 642k tokens, with zero court.
• No CLI-version regression: the 56 span 5 versions and are absent on heavily-used intermediate ones (2.1.158, .167 — ~1.6k Opus generations each, 0 court; also 2.1.173 at lighter ~190-generation exposure). The apparent per-version concentration is single-session cascades (16 and 30 events inside one session each); on the unbiased onset metric the two newest versions actually failed at higher context than older ones — no evidence they fail sooner. (Cascade severity being worst on the two newest versions is a weak n=1–2 hypothesis, not established.) The strong correlate is the model (100% Opus 4.8).

Why this is worse than "transcript noise" — a data-integrity failure

The current Impact section frames this as noise / wasted turns / operator confusion. On Linux we observed a stronger failure mode that argues for higher severity:

• Because the call is silently dropped (stop_reason still says tool_use, but nothing executed), an agent that does not independently re-verify can proceed as if the call had succeeded — yielding false "completed / verified" records. (This is a joint product of the drop and an agent's own verify discipline — but the silent, tool_use-still-set nature of the drop is what makes it easy to miss.)
• In our case this was only caught by re-auditing the live system in a later session and finding claimed-done changes were not actually deployed.
• Smoking gun: one dropped call was the agent's own attempt to correct a phantom record — the text reads …correcting the phantom/overstated record immediately before the stray court, and that correction was itself eaten. The bug can block its own remediation.

This turns an annoyance into silent state/decision corruption: downstream reasoning trusts records of tool calls that never happened.

Unrecoverable within a session

Once it begins, it persists for the rest of the session across the operator's retry attempts within the same task; the only reliable recovery we found is a full session reset (fresh session + handoff doc). In one workstream this cost 3 consecutive sessions. (We did not isolate whether a literal session-resume re-inherits the corruption vs. the same long-context state re-triggering it; we only observed it does not clear without a reset.)

Not established (kept honest)

• Root cause / why the token is specifically court.
• Whether the silent-drop vs cosmetic split is a property of model state, surrounding prose, or tool path.
• The false-completion effect requires the agent proceeding on a dropped call; we have not isolated whether prompt/verification changes its rate. (We are tightening our own verify-before-claim discipline regardless; that does not fix the underlying drop.)

Ask

Given (a) it is not OS-specific (macOS + Windows already, and this Linux repro — platform:linux now added), (b) it can produce silent false-completion records, and (c) in our data it is exclusively Opus 4.8 (0 on Fable 5 / Opus 4.7 / Haiku) yet the Fable-5 fallback is now access-restricted for us — leaving no model-switch workaround — please consider raising severity above cosmetic. Happy to share a sanitized JSONL excerpt of the dropped-call events.

Detector we used (reproduces the 56 = 46 shape-A + 10 shape-B):

import json, glob, re
B = re.compile(r"(?i)(^|\n)\s*(court|count)\s*\n+\s*(<invoke\b|antml:invoke)")
for f in glob.glob("<project>/*.jsonl"):
    for line in open(f, encoding="utf-8", errors="replace"):
        try: o = json.loads(line)
        except: continue
        if o.get("type") != "assistant": continue
        m = o.get("message", {}); c = m.get("content", [])
        if m.get("stop_reason") != "tool_use" or not isinstance(c, list): continue
        if any(b.get("type") == "tool_use" for b in c if isinstance(b, dict)): continue
        txt = "\n".join(b.get("text","") for b in c if isinstance(b, dict) and b.get("type") == "text")
        shapeA = txt.rstrip().lower().endswith(("court", "count"))   # stray token at end
        shapeB = bool(B.search(txt))                                  # token then raw <invoke> as text
        if shapeA or shapeB:
            print(o.get("timestamp",""), m.get("model"), "A" if shapeA else "B")

---
Edited shortly after posting to correct the cluster platform breakdown (macOS + Windows, not all-macOS), make the published detector reproduce all 56 events (shape A + B), drop non-load-bearing per-version percentages, and soften the resume-contagion wording to what the logs directly show.

Confirming this cluster on Claude Code 2.1.175 / Windows 11, with one variant I haven't seen explicitly called out here: the leaked tool-call (invoke) block was emitted twice (duplicated, identical).

Context: mid-session, during an ordinary Edit on a local file. Instead of executing, the tool call leaked as literal text -- a leading court token followed by raw invoke markup -- with no tool result returned. The file was never written (verified by re-reading: original content intact), yet the assistant reported "I've applied the fix" and continued reasoning on that false premise. A fresh session re-applied the same edit cleanly.

The variant -- the same Edit block appeared duplicated back-to-back, identical (placeholders only, no real content/paths):

court<invoke name="Edit">
<parameter name="file_path">path/to/file</parameter>
<parameter name="old_string">OLD</parameter>
<parameter name="new_string">NEW</parameter>
</invoke>

<invoke name="Edit">
<parameter name="file_path">path/to/file</parameter>
<parameter name="old_string">OLD</parameter>
<parameter name="new_string">NEW</parameter>
</invoke>

I've applied the fix.   (but path/to/file was unchanged on disk)

Closest scenario match I found is #69370 (silent Edit/Write failure, file not modified, assistant believes it succeeded). The silent + false-success behavior is the dangerous part -- no error surfaces, so subsequent steps build on an edit that never reached disk.

Environment

• Claude Code 2.1.175
• Windows 11 (10.0.26200), PowerShell
• Model in the broken session: couldn't reliably determine

Caveat: intermittent, no deterministic repro, and I didn't capture the raw .jsonl, so I can't confirm whether court is in the model's generated output vs. a render artifact. Happy to attach a sanitized transcript excerpt if I manage to reproduce.

Corroborating data point — same mechanism, but with a different stray token (count) and an inverse tool distribution, both of which I think strengthen the serialization/tokenization-corruption read.

The stray token varies per environment. On my machine the leading token is consistently count, never court/call. 100% of my occurrences match the exact shape <assistant prose> → blank line → a lone count line → bare <invoke>:

<assistant reasoning text> ...

count
<invoke name="Bash">
<parameter name="command">cd <repo> && <command></parameter>
</invoke>

That the stray token differs across users (court / call / count) while everything else is identical points to a variable model-side artifact rather than a fixed string.

No tool_use block at all → the call truly never runs. In every one of my occurrences the assistant message carries only a text content block and zero tool_use blocks, so nothing executes and the turn dead-ends (it reads as a silent stop). Re: the note here that "sometimes the underlying tool still executed" — on my side that never happens; when the markup leaks into text there is no tool_use block, so the only way a tool runs is a separate, well-formed retry.

The affected tool set is the inverse of this report. You saw mostly Edit/Read with Bash unaffected; mine is mostly Bash (42/53), with Edit/Read/internal task-update calls also hit. So the affected tools aren't fixed either — another sign the corruption is upstream of any specific tool.

It tracks the model, not the CLI build. Reproduces identically across three CLI versions — 2.1.183, 2.1.185, 2.1.193 — all on claude-opus-4-8.

Other structural facts from the raw transcript JSONL:

• Tags are bare <invoke> / <parameter> — the antml: namespace prefix is dropped.
• stop_reason is split across occurrences: ~66% end_turn, ~34% tool_use (the API signalled a tool turn but the body was plain text with no tool_use block).
• The leaking turn has no thinking block.
• Both single-invoke and multi-invoke (parallel) turns are affected.

Frequency: 53 occurrences across 3 long sessions over ~6 days, up to 41 in a single long, tool-heavy session. Well-formed (namespaced) calls work fine in between, and once it starts it tends to recur within the same session.

Rules out a transport/proxy cause: first-party Anthropic API only — no ANTHROPIC_BASE_URL override, no Vertex/Bedrock; responses carry genuine req_011C… request IDs. The CLI is launched through a thin wrapper that only restores NODE_OPTIONS and does not touch the API transport.

My usage profile (likely the trigger shape): very long, multi-hour single sessions with heavy heterogeneous tool orchestration (dozens to hundreds of calls), frequent parallel tool dispatch within one turn, one git worktree per task (so lots of nested cd / Edit paths), high reasoning effort, subagent fan-out, and the occasional /compact followed by more heavy tool use. The leaks cluster in exactly these long, orchestration-heavy sessions.

Mitigation that holds up in practice: bail to a fresh session as soon as it starts — in-session retries tend to make it worse because the broken block stays in history and self-reinforces. Happy to share more redacted transcript structure if it helps.

<img width="2078" height="1620" alt="Image" src="https://github.com/user-attachments/assets/6b98baf4-145f-4482-8c73-348220e43ba8" />

Reproduction with Opus 4.8 in an orchestration/monitoring workflow (large accumulated context + screenshots)

Confirming this on Opus 4.8 (claude-opus-4-8) via Claude Code CLI. The stray court token reliably appears and then degenerates into a long repetition loop once the context gets large.

Setup

• Model: Opus 4.8 (1M context)
• Role: orchestrator coordinating multiple background worker sessions (tmux-based)
• Workflow: repeatedly calling Bash to capture terminal panes (tmux capture-pane) to monitor worker progress

What triggers it
The failure mode kicks in after the context grows large from repeated big tool outputs — specifically, full tmux capture-pane dumps of a very wide terminal pane (hundreds of lines, lots of box-drawing chars), plus a couple of pasted screenshots. Once the conversation gets heavy:

1. Instead of emitting a proper <invoke> tool call, the model emits the literal token court as plain text.
2. The tool call does not execute.
3. The model does not self-correct — it falls into a loop emitting court on its own line, hundreds of times in a row, burning the context window (got to ~237k tokens before the user interrupted).

Observed output (verbatim)

court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
court
... (continues for hundreds more lines until the user pressed Esc)

Aggravating factors I could correlate

• Large/wide tool outputs right before the failing turn (wide tmux pane captures).
• Accumulated screenshots in context.
• High total token count — the larger the context, the more reliably it happens.

Workaround that helped
Switching from full pane dumps to compact, filtered Bash commands (e.g. grep-ing a single status line instead of capture-pane | tail) drastically reduced context growth and made the failures much rarer.

Environment

• Model: claude-opus-4-8
• Platform: macOS (darwin)
• Claude Code CLI

This lines up with the 1M-context / large-context reports (#64150, #69237) — the common denominator is heavy accumulated context (esp. large tool outputs + screenshots) causing the tool-call serialization to emit court instead of the invoke tag, with no recovery.

A possible hint about why "court": I've seen once or twice written "courtesy" instead of "court" before the <invoke> block.

Today, I got some new ones, never seen before:

court

court

courceforge

courceforge

courceforge

court

and then:

court

courthood

court

• tons of those... Leading up to:

court

courthood

● API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task.

  Request ID: req_011CcYz6zDWBJTgn2JvnRVcb

(if that ID serves someone up there to trace the issue...)

Later:

My apologies — my previous response malfunctioned and emitted garbage. Recovering now. [...]

Did the model just snap? As long as we don't have court\n\ncourt\n\nlaunching nukes\n\ncourt\n\n we're good ;-)

(2.1.191 running, Windows, latest installed 2.1.196 but .191 still present as claude.exe.old.1782712141489)

This also serves as a test... to see if anyone at Anthropic is actually reading this (if so, we'll get at least a platform:windows label on this one...).

Reproduced on Claude Code CLI, Opus 4.8 with 1M context. Same signature: stray court token then raw <invoke>/<parameter> markup emitted as assistant text, so the tool never executes and the turn stalls.

Data point on the trigger: it first appeared ~6 hours into a long session (~3.6 MB transcript, ~790 assistant turns) and recurred ~8 times over the next several hours. Roughly 40% of assistant turns still produced valid tool_use blocks — so it's intermittent, not a hard break. The turns right before the first failure were ordinary small tool calls with small results — no large or malformed input preceded it. Strong correlation with session length / context load; once it starts the session is unrecoverable and only kill-and-restart clears it.

I had this last week while using Cowork in the Windows Claude desktop app. I was using the Computer Use plugin and it happened several times and got totally stuck just printing the word "court" over and over. I reported/submitted the sessions via the app's thumbs-down button.

Today I've also seen "court" printed a few times in a completely different Claude Code CLI session.

It's sometimes hard to reconcile having this +2 months serious and puzzling issue and its dozens of duplicates still alive and the narrative we keep hearing about each Anthropic engineer closing dozens of PRs a day... Either that particular type of bug managed to slip through, or by "closing PRs", they actually meant "closing PRs as dupes" :-P

Some kind of "we know about it and someone's working on it" feedback would be encouraging...