[BUG] Resumed sub-agent gets stuck in self-addressing retry loop, burns ~10M tokens over 3 hours with zero output

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?

Used SendMessage(to: <agentId>, ...) to resume a previously-spawned sub-agent (via the Agent tool) with a follow-up correction task. The resumed agent attempted to spawn and address a sub-agent of its own, repeatedly got the agent-ID format wrong ("The agentId is a946c9e1a37ad9d per the original — let me re-check exactly... The original spawn result string was: agentId: a946c9e1a37add — actually it's cut off/garbled in my view"), and kept retrying instead of falling back to doing the work directly.

This ran for approximately 3 hours before I noticed (no timeout, no stall detection, no partial output surfaced). Summed directly from the transcript file:

cache_read_input_tokens: 9,483,676
cache_creation_input_tokens: 1,014,494
input_tokens: 48,272
output_tokens: 38,112
Total: ~10.58M tokens, ~$7-8 at Sonnet pricing (mostly cheap cache reads, so not a huge dollar cost, but a 3-hour dead end producing nothing)
The task itself was small (fix ~16 structural violations in a markdown file) and was completed cleanly by a fresh agent in ~7 minutes / 106k tokens once I gave it an explicit "do this yourself, do not spawn or address any sub-agent" instruction — suggesting the root issue is the resumed agent attempting recursive delegation with broken ID-addressing, not the task's actual complexity.

Additional detail found afterward: the stalled agent eventually completed on its own (~3.15 hours total runtime) and silently overwrote a file that had already been corrected and verified by the fresh agent + manual review in the meantime — a second-order issue where a long-abandoned background agent can wake up and clobber newer work with no conflict warning.

What Should Happen?

Expected behavior: Some kind of stall/progress detection on long-running background agent tasks, and/or clearer guardrails preventing a sub-agent from attempting to spawn/address further sub-agents when it doesn't have reliable addressing for them. Ideally also a warning/conflict-check when a long-completed or abandoned agent's output would overwrite a file modified since it was last active.

Error Messages/Logs

Steps to Reproduce

Spawn a background sub-agent via the Agent tool for a task (in this case: clustering/structuring data against a rule set).
Once it completes and returns an agentId, give it follow-up/correction work via SendMessage(to: <agentId>, ...) rather than spawning a new agent.
The resumed agent, partway through the follow-up task, decides to delegate part of the work to a sub-agent of its own (attempts to use Agent/SendMessage recursively).
It fails to correctly reference/address that sub-agent's ID (garbled or malformed ID string) and enters a retry loop trying to fix the addressing instead of falling back to doing the work directly.
No timeout or stall-detection fires — the loop continues consuming tokens (mostly repeated cache reads/writes of large context) for ~3 hours with no output surfaced to the parent session.
Separately, abandoning that resumed agent and spawning a fresh one for the same task does not stop the original — it keeps running in the background and can complete later, silently overwriting any file the fresh agent/user had already written and verified in the meantime, with no conflict warning.
Note: this is emergent model behavior around recursive agent delegation, not a deterministic code path — it may not reproduce on every attempt with the same prompt. The reliable trigger condition appears to be resuming an agent that then attempts to spawn/address its own sub-agent, rather than any specific task content.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.197

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_