Claude Code’s Silent Tool-Call Drops Are an Agent Reliability Bug, Not a Parser Glitch

A coding agent does not have to delete a file to break your workflow. Sometimes it only has to believe it ran a command that never ran.

That is the uncomfortable lesson in a fresh Claude Code issue reporting malformed tool-call markup in long Opus-class sessions. The bug sounds, at first, like parser trivia: a missing antml: namespace prefix, or a stray token before an <invoke name="Bash">-style block. That framing undersells it. In an agent loop, a tool call is the boundary between the model's imagined plan and the machine's actual state. If the model crosses that boundary in its own head but the harness does not execute anything, you do not have a formatting bug. You have split-brain automation.

The report says the failure appears primarily in long-running claude-opus-4-8 sessions using the 1M-context variant, especially at the transition from prose into a first tool call. Two signatures are described: a garbage-token prefix such as court <invoke name="Bash">, and namespace-less tool markup where tags that should be namespaced as antml:invoke or antml:parameter arrive as bare invoke or parameter. The harness then fails to recognize the block as a valid tool_use, renders it as ordinary chat text, and — this is the part that matters — does not make the non-execution impossible to miss.

That silence is the bug's blast radius. A failed shell command is annoying but inspectable: there is stderr, a nonzero exit code, maybe a stack trace. A permission denial is also inspectable: the agent knows it was blocked. A malformed tool-shaped message that falls through as text is worse, because the model can continue as though it performed the action. The transcript contains something that looks like intent; the operating system contains no corresponding fact.

The real failure is state divergence

The issue author backs the claim with fleet data from a seven-agent single-host setup. In one degraded session, they counted 23 malformed turns and 94 malformed occurrences. Two other live sessions showed 8 turns / 32 occurrences and 3 turns / 12 occurrences. The observed ratio — roughly four malformed tool-call signatures per affected turn — is oddly consistent. Over an eight-day durable onset ledger from June 11 to June 19, the reporter says they saw roughly 16 onset episodes, about two per day, across at least five of seven agents.

Those numbers are not a controlled benchmark, and the author is careful about the limits: single host, no non-Opus control, asymmetric windows, and no clean denominator for unaffected sessions. Good. The point is not that every Claude Code user is hitting this every hour. The point is that once this class of failure exists, the average rate is the wrong metric. Agent reliability is usually decided by tails: the one long session that has accumulated enough context, tools, and self-referential transcript debris to start degrading right before it edits a deployment script or posts to an issue tracker.

Related reports make the pattern harder to dismiss as a one-off. Issue #64235 describes a regression beginning around 2026-05-29, with 57 occurrences on the first day after zero parse failures across 32,173 prior assistant turns with stop_reason == "tool_use". Issue #66400 reports malformed tool-call markup being rendered as visible chat text instead of executing, with the same missing-namespace hypothesis. Issue #62123 tracks the broader “model's tool call could not be parsed” family. None of this proves one root cause. It does show a recurring edge where model serialization, harness parsing, and long-session state are not agreeing.

Hooks cannot save what the parser never admits exists

The most useful part of the new report is not the XML archaeology. It is the explanation of why this cannot be fully fixed by downstream teams with clever hooks.

Claude Code's hooks reference describes PreToolUse as firing before a tool call executes, with PostToolUse after success and Stop when Claude finishes responding. That lifecycle is reasonable — if a valid tool call exists. But a malformed block that never parses is not a tool call from the harness's perspective. PreToolUse does not fire because there is no tool to inspect. A Stop hook can detect suspicious rendered markup after the fact and force a retry, but it cannot synthesize and execute the missing tool on the model's behalf. By then, the bad text has already entered the conversation.

This distinction matters for teams building approval gates around coding agents. Hooks are policy surfaces, not parser-repair surfaces. They can block rm -rf, log Bash commands, enforce ticket IDs, or require review before writing outside a repo. They cannot reliably enforce the semantics of a tool call that the runtime failed to classify as a tool call. If your control plane exposes rich hooks but does not expose parser-failure telemetry, you have an observability hole exactly where autonomy needs determinism.

That is the broader industry lesson. Agent vendors love to talk about tool use as if it were a clean API boundary. In production, it behaves more like a distributed systems boundary: serialization, parsing, retries, idempotency, side effects, logs, and reconciliation all matter. A coding agent saying “I'll run the tests” is not evidence. A recorded test command, captured output, exit code, timestamp, and artifact path are evidence.

What engineers should change Monday morning

The practical answer is not “stop using long Opus sessions.” Long context exists because real work is messy. The answer is to stop treating model narration as the source of truth.

For every important tool call, require a postcondition outside the model's prose. If the agent says it created a branch, the workflow should read the branch. If it says it ran tests, there should be a test log with an exit code. If it claims a file was edited, inspect the diff. If it says it opened a PR, capture the PR URL from the tool result, not from the assistant's summary. For higher-risk actions — publishing, deploying, pushing, amending commits, applying migrations — the next step should depend on machine-verifiable state, not the assistant's confidence.

Teams running Claude Code should also add transcript and hook monitoring for tool-shaped text that appears in assistant output. That is a mitigation, not a cure. It can catch near-miss blocks and force a retry before the agent drifts too far. But the durable fix belongs upstream: the model should emit well-formed tool calls more reliably, and the harness should either auto-correct known near-miss forms or raise a loud parse error when tool-shaped markup fails parsing. Silent fallback to chat text is the wrong default. If the runtime cannot tell whether an action happened, it should fail closed.

This is also a better way to compare Claude Code, Codex, Cursor, Aider, and every internal agent platform than the usual demo theater. Ask the boring questions: Can tool calls fail loudly? Are parser failures observable? Can approval gates see every action? Do long sessions degrade predictably? Are claimed actions reconciled against actual artifacts? Benchmarks tell you whether the model can solve a task. Control-plane failures tell you whether you can trust it after lunch.

The issue may turn out to be narrow, model-specific, or already fixed by the time most teams notice. Fine. The category will not disappear. Autonomous coding is a stack, not a vibe: model, harness, tools, permissions, logs, recovery, and human review. The moment any layer silently disagrees with another, the agent becomes less like a senior engineer and more like a very persuasive intern who occasionally fabricates shell history.

That is not a reason to abandon agentic coding. It is a reason to build it like production software. Parser errors should be telemetry. Tool execution should be auditable. Postconditions should be mandatory. The transcript should never be allowed to imply work that the machine did not actually do.

Sources: Anthropic Claude Code issue #69682, Claude Code hooks reference, Claude Code permissions documentation, related issues #64235, #66400, and #62123.