›_ Claude Code Issues
Claude Code Issues / #75053

[BUG] Claude repeatedly emits malformed tool calls (missing outer `function_calls` block

Open 💬 0 comments Opened Jul 7, 2026 by mayu-hirata

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?

Bug report — Claude repeatedly emits malformed tool calls (missing outer function_calls block)

Summary

During an extended working session, the assistant repeatedly emitted malformed tool calls that could not be parsed, causing the tool to not execute and the turn to abort. The user had to intervene ("continue" / re-prompt) each time. This happened 20+ times in a single session — a persistent, high-frequency failure, not an isolated slip. It recurred even immediately after the assistant had written a rule specifically to prevent it.

Product

  • Claude Code (VS Code extension environment)
  • Model: Claude Opus 4.8 (1M context) — claude-opus-4-8[1m]

Severity / impact

  • Severe, repeated work stoppage. Every occurrence halts the current action and forces the user to re-prompt. Over 20 occurrences in one session made sustained work nearly impossible and caused significant, repeated user frustration.
  • Self-correction does not hold. The assistant apologized many times and even authored an internal guardrail documenting the exact failure, then reproduced the same failure on the very next tool call. Stated constraints are not reliably applied on the following generation step.

Reproduction pattern (consistent trigger)

The malformation was not random. It clustered around one specific situation:

  1. The assistant completes a substantive edit correctly (a well-formed Edit/Write call succeeds).
  2. The assistant then writes a paragraph of prose to the user.
  3. After the prose, the assistant appends a follow-up tool call — often a single Bash running grep to verify the result, or a Bash open to preview.
  4. On that appended call, the assistant omits the outer function_calls block and starts directly from invoke name="...", producing output the harness cannot parse.

Trigger in one line: a tool call tacked on after prose, following a successful primary edit — the enclosing block is dropped.

Expected behavior

Every tool invocation must be wrapped in the correct outer block (function_calls -> invoke -> parameter -> matching closing tags). The model must never begin a tool call from a bare invoke without the enclosing block.

Actual behavior

The follow-up/verification tool call is emitted starting at invoke, with the enclosing function_calls block missing. The harness returns a "malformed / could not be parsed" error and the turn stops.

Frequency in this session

20+ occurrences, all matching the pattern above. Critically, it recurred immediately after the assistant added a written guardrail describing this exact failure mode. This strongly indicates the issue is not fixable by in-context self-instruction alone and needs a model- or harness-level safeguard.

Suggested areas to investigate

  • Why appended/trailing tool calls (after prose) drop the outer wrapper far more often than the first tool call in a turn.
  • Whether long sessions / large accumulated context raise the rate of this specific structural omission.
  • A harness-side safeguard: if a turn's tool output begins with a bare invoke (no enclosing function_calls block), auto-wrap it or return a targeted correction hint, instead of a generic parse failure that silently stalls the user.
  • Whether reinforcing "one well-formed tool block per action; do not append verification calls after prose" reduces occurrences.

Where to file

What Should Happen?

Bug report — Claude repeatedly emits malformed tool calls (missing outer function_calls block)

Summary

During an extended working session, the assistant repeatedly emitted malformed tool calls that could not be parsed, causing the tool to not execute and the turn to abort. The user had to intervene ("continue" / re-prompt) each time. This happened 20+ times in a single session — a persistent, high-frequency failure, not an isolated slip. It recurred even immediately after the assistant had written a rule specifically to prevent it.

Product

  • Claude Code (VS Code extension environment)
  • Model: Claude Opus 4.8 (1M context) — claude-opus-4-8[1m]

Severity / impact

  • Severe, repeated work stoppage. Every occurrence halts the current action and forces the user to re-prompt. Over 20 occurrences in one session made sustained work nearly impossible and caused significant, repeated user frustration.
  • Self-correction does not hold. The assistant apologized many times and even authored an internal guardrail documenting the exact failure, then reproduced the same failure on the very next tool call. Stated constraints are not reliably applied on the following generation step.

Reproduction pattern (consistent trigger)

The malformation was not random. It clustered around one specific situation:

  1. The assistant completes a substantive edit correctly (a well-formed Edit/Write call succeeds).
  2. The assistant then writes a paragraph of prose to the user.
  3. After the prose, the assistant appends a follow-up tool call — often a single Bash running grep to verify the result, or a Bash open to preview.
  4. On that appended call, the assistant omits the outer function_calls block and starts directly from invoke name="...", producing output the harness cannot parse.

Trigger in one line: a tool call tacked on after prose, following a successful primary edit — the enclosing block is dropped.

Expected behavior

Every tool invocation must be wrapped in the correct outer block (function_calls -> invoke -> parameter -> matching closing tags). The model must never begin a tool call from a bare invoke without the enclosing block.

Actual behavior

The follow-up/verification tool call is emitted starting at invoke, with the enclosing function_calls block missing. The harness returns a "malformed / could not be parsed" error and the turn stops.

Frequency in this session

20+ occurrences, all matching the pattern above. Critically, it recurred immediately after the assistant added a written guardrail describing this exact failure mode. This strongly indicates the issue is not fixable by in-context self-instruction alone and needs a model- or harness-level safeguard.

Suggested areas to investigate

  • Why appended/trailing tool calls (after prose) drop the outer wrapper far more often than the first tool call in a turn.
  • Whether long sessions / large accumulated context raise the rate of this specific structural omission.
  • A harness-side safeguard: if a turn's tool output begins with a bare invoke (no enclosing function_calls block), auto-wrap it or return a targeted correction hint, instead of a generic parse failure that silently stalls the user.
  • Whether reinforcing "one well-formed tool block per action; do not append verification calls after prose" reduces occurrences.

Where to file

Error Messages/Logs

Steps to Reproduce

Setup — start Claude Code (VS Code, Opus 4.8 1M context) on any repo
Minimal artifact — a single command to create /tmp/repro.txt (the only file needed)
The trigger prompt — a task that forces the exact rhythm that breaks it: edit → explain in prose → verify with grep, repeated
What a correct call looks like — the primary Edit emitted with the full function_calls wrapper
What the bug looks like — the appended verification grep emitted from a bare invoke, missing the outer block, with the resulting parse error
How to raise the hit rate — long session / large context, and always placing the verification call after prose

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.186 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Cursor

Additional Information

_No response_

View original on GitHub ↗