Stray "call"/"court" token before tool calls; internal <invoke> XML printed as text instead of executing (Windows local + cloud Cowork)

Open 💬 7 comments Opened Jun 14, 2026 by wonjoongkim-dev

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Occasionally, instead of cleanly executing a tool call, Claude Code emits a stray plain-text token — "call" or "court" — and then prints its internal tool-call markup (<invoke name="..."><parameter ...>...</parameter></invoke>) to the user as literal text. The call does not run. Re-issuing the request usually works and no files are corrupted, so the harm is garbled output and an interrupted workflow rather than data loss.

What Should Happen?

The tool call should execute normally: no stray "call"/"court" token should appear, and the internal <invoke> markup should never be shown to the user as text. The action should run on the first attempt.

Error Messages/Logs

# Verbatim leak (cloud Cowork session, tool mcp__workspace__bash). The stray
# token (call / court) is emitted as plain text, immediately followed by the
# internal <invoke> XML rendered literally instead of executing. The block also repeats.

call
<invoke name="mcp__workspace__bash">
<parameter name="command">cd "/sessions/zen-inspiring-knuth/mnt/English Master Project" && grep -c "이미지키 ↔ AI회화 키 분리 상태" docs/ops/할일_리스트_마스터.md</parameter>
</invoke>

court
<invoke name="mcp__workspace__bash">
<parameter name="command">cd "/sessions/zen-inspiring-knuth/mnt/English Master Project" && grep -c "이미지키 ↔ AI회화 키 분리 상태" docs/ops/할일_리스트_마스터.md</parameter>
</invoke>

court
<invoke name="mcp__workspace__bash">
<parameter name="command">cd "/sessions/zen-inspiring-knuth/mnt/English Master Project" && bash tools/release_check.sh 2>&1 | tail -5</parameter>
</invoke>

Steps to Reproduce

Note: This is intermittent and not reliably reproducible on demand. It is not tied to any specific file or command — it appears to be triggered by model output formatting, not by a user action. Below is the pattern under which it has consistently appeared:

  1. Open a Claude Code session and work normally, issuing many tool calls over an extended session (it clusters later in long, tool-call-heavy sessions).
  2. Before a tool call, the model emits a stray plain-text token — "call" or "court" — instead of cleanly invoking the tool.
  3. The harness rejects the malformed call, and the model's internal <invoke name="..."> ... </invoke> XML is printed to the user as literal text instead of being executed.
  4. The same tool-call block is often emitted twice (repeated).
  5. Re-running the request usually succeeds; no files are corrupted. The impact is garbled output and an interrupted workflow, not data loss.

Observed across two independent environments (see Additional Information), which suggests the cause is model-side rather than environment-specific.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.12603.1.0

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This is not specific to one machine or OS. The same behavior — a stray "call"/"court" token followed by the internal <invoke> XML being printed as text instead of executing — has appeared in two independent environments:

  1. Local: Claude Code on Windows 11 (PowerShell).
  2. Cloud: a Claude "Cowork" sandbox session (Linux), with the leaked block referencing mcp__workspace__bash and a /sessions/.../mnt/ path.

It has also been seen on more than one model (Fable and Opus). Because it spans different OSes, environments, and models, the cause appears to be model-side output formatting rather than any local setup.

It is intermittent — the large majority of tool calls are clean — and it tends to cluster later in long, tool-call-heavy sessions. Re-running the request normally succeeds and no files are corrupted. Screenshots attached.

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗