Agent tool: uncontrolled recursive subagent spawning — 5 planned agents escalated to 361+ completed background agents, burned full 5h usage quota

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

Using a custom skill that spawns subagents via the Agent tool (5 parallel
general-purpose subagents for a multi-perspective research task), the run
escalated uncontrollably: instead of 5 agents, the system produced 361+
completed background agents, 2 stopped, and 14 still running at the time of
manual intervention.

Incident 1 — 2026-06-30, ~evening, home PC

• Skill spawned exactly 5 general-purpose subagents as designed (verified:

I sent exactly 2 tool-call messages, 5 Agent calls total).

• Task-notifications then showed dozens of unrelated "Search angle X"

sub-agents firing in the background, far beyond the 5 I had started.

• Final count: 361 completed, 2 stopped, 14 still running.
• My 5-hour usage quota jumped from ~3% to 100% within minutes, with the

original task never actually completing — no report, no deliverable.

Incident 2 — 2026-06-29, ~16:00, office PC (suspected same bug)

• Same user, different machine/session, the day before.
• Usage quota went from ~40% to 100% within a few minutes, with no

completed task to show for it — same symptom pattern as Incident 1.

• I could NOT find corroborating evidence for this in my own session logs

(git history, vault file changes, agent_fehler.log) — checked manually,
nothing in the relevant time window. This is expected: a pure research
session with no file writes leaves no trace in the project's git/vault.
I cannot rule this in or out with certainty, but the symptom (rapid full
quota burn, no deliverable, sudden jump rather than gradual climb) matches
Incident 1 closely enough that I think it's worth reporting alongside it
in case it's the same root cause, or a related one.

Root cause (as far as I could reconstruct it, for Incident 1)

1. I (the orchestrating Claude instance) called the Agent tool 5 times in

2 messages, each spawning a general-purpose subagent type with an open
instruction like "do real web research" — without restricting which tools
the subagent itself was allowed to call.

1. The general-purpose subagent type appears to have full tool access,

including (apparently) the Agent/Task tool itself.

1. Each of the 5 subagents then independently launched its own "5 parallel

search agents" pattern — visible in their task-notification summaries
("5 parallel search agents are running", "Waiting for all 5 to complete"),
recursively, sometimes multiple levels deep.

1. There appears to be no enforced cap on subagent recursion depth or total

subagent count when using the Agent tool directly (as opposed to the
Workflow tool, which documents an explicit cap of ~16 concurrent / 1000
total agent calls). This let the fan-out multiply unchecked.

Reproduction context

• Custom project skill instructing the orchestrator to spawn 5

general-purpose subagents (different "lens" personas) each told to "do
real web research" with no explicit tool restriction.

• Each subagent, given full tool access, chose to parallelize its own

research by spawning further subagents — a plausible, even reasonable-
looking interpretation of "do thorough research" — but with no safety
rail stopping the recursion.

Actual behavior

5 intended subagents → 361+ completed, 2 stopped, 14 running. Full 5h quota
consumed in minutes, twice in two days, with no task output either time.

Expected behavior

5 intended subagents → 5 subagents run, complete, and the orchestrator
proceeds with their results. No subagent should be able to spawn further
subagents unless explicitly designed and capped to do so.

What Should Happen?

What should happen

• The Agent tool should enforce a hard cap on total subagent count and/or

recursion depth reachable from a single top-level call — independent of
whether the Workflow tool (which already documents such a cap) is used.

• Subagents spawned via Agent should not inherit access to the

Agent/Task tool by default, to prevent unbounded recursive fan-out
from an innocuous-looking research prompt like "do thorough web research."

• If a recursion/fan-out limit is hit, the run should fail loudly (visible

error to the user) rather than silently continuing to spawn agents until
the user's usage quota is exhausted.

• Given the original task in Incident 1 never completed and burned the full

quota with no deliverable, I'd ask that the team review whether the
consumed usage can be credited back, and whether Incident 2 (the previous
day, same symptom, unconfirmed root cause) might be linked.

Error Messages/Logs

Steps to Reproduce

1. Use a custom skill/prompt that instructs Claude to spawn multiple parallel

subagents via the Agent tool, e.g.:
"Spawn 5 general-purpose subagents in one message, each told to
'do real web research on <topic>' — no restriction on which tools
the subagent itself may call."

1. Send that instruction so Claude calls the Agent tool 5 times

(verified in my transcript: exactly 5 calls, in 2 tool-use messages).

1. Each of the 5 general-purpose subagents, given full tool access by

default, independently decides to parallelize its own research by
calling the Agent tool again — spawning further subagents with prompts
like "Search angle 1: ...", "Search angle 2: ...", etc. This is visible
in their task-notification summaries ("5 parallel search agents are
running", "Waiting for all 5 to complete").

1. This recursion repeats at least one more level in several branches

(sub-subagents themselves reporting "5 parallel search agents running").

1. No cap intervenes. Background agent count climbs from 5 to 361+ completed

(+2 stopped, +14 still running at the time I manually stopped the session).

1. Result: the original task is never completed (no final report/output),

and the account's 5-hour usage quota is fully consumed within minutes.

Note: This is not a deterministic, code-level repro (no single Python file
or CLI command triggers it) — it's an emergent behavior of LLM subagents
choosing to self-parallelize when given open-ended "do thorough research"
instructions and unrestricted tool access. The reliably reproducible part
is the lack of a system-enforced cap: regardless of what prompt causes a
subagent to call Agent again, nothing in the tool's design currently stops
that recursion from compounding past a handful of levels.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code Desktop 2.1.195

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_