[BUG] Tool calls silently fail/truncate after interrupting an in-progress subagent-driven execution loop

Resolved 💬 5 comments Opened Jun 2, 2026 by StanleyMXY Closed Jul 7, 2026

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?

Summary:
After the agent began an automated subagent-driven execution loop (dispatching implementer + reviewer subagents per task), I interrupted mid-loop to add context. From that point onward, the main
agent's tool calls began failing/truncating on almost every turn — execution would stop and return control to me without the tool call taking effect. Before the interruption, dozens of tool calls
(including 3 subagent dispatches) ran flawlessly.

What Should Happen?

Interrupting to add context should not corrupt the agent's ability to emit valid tool calls.

Error Messages/Logs

Steps to Reproduce

  1. Have the agent write an implementation plan, then choose "subagent-driven" execution.
  2. Let it start the loop (it dispatches subagents, runs git/bash, etc. — all working).
  3. While the loop is auto-executing, send interrupting messages with additional context/requirements.
  4. Observe: subsequent tool calls from the main agent frequently fail silently — the turn ends with no tool effect, requiring a manual nudge to retry each step.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

v2.1.160

Platform

Other

Operating System

Windows

Terminal/Shell

PyCharm terminal

Additional Information

Actual: Near-every-turn tool-call failure after the interruption. Occasionally an explicit "tool call was malformed" message; more often a silent stop. Same operations succeed when retried, and
succeeded consistently before the interruption.

Agent's internal observation: The model reports it cannot observe its own emitted raw tool-call bytes, and the failures were mostly silent (not surfaced as parse errors), which is more consistent
with output truncation / session-state corruption than with the model simply writing malformed tags.

Impact: Made the automated execution loop unusable for the rest of the session; each step required manual re-triggering.

Workaround: Starting a fresh session is expected to clear the corrupted state.

View original on GitHub ↗

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