[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated subagent work.

[lonlundgren]

Multiple regressions compound into a catastrophic token burn scenario. Subagents recursively spawn child agents 50+ levels deep, ignoring CLAUDE_CODE_FORK_SUBAGENT=0. Permission denials trigger further agent spawning instead of stopping. Agents fetch individual files from GitHub repos via HTTP (one WebFetch or curl per file, each with a full prompt and context payload) instead of cloning locally. Subagent permissions do not propagate to the user for approval. And if the user interrupts any of this, all intermediate work from every agent in the tree is lost. The entire token spend goes in the garbage.

In the observed case: 1.2M+ tokens consumed in ~30 minutes on a task that should have been git clone + find . -name '*.sol'. The recursive agent tree was still growing when observed.

In another instance, this same pathological behavior consumed an entire Pro Max 20x plan 5-hour session token limit in under 5 minutes (4 million tokens consumed).

This is a major regression that shipped on or around June 10th.

Impact

This behavior has repeatedly consumed 5-hour session limits in minutes. Over 50% of a weekly Max x20 plan limit has been burned by errant subagent recursive spawning. Most recently, a 5-hour session window was consumed in under 5 minutes of subagent work, pushing the weekly limit to 80% utilization with 5 full days until reset.

The out-of-control recursive subagents also trigger rate limits. Subagents in the spawn tree then trigger immediate retries, hammering token limits even faster for entirely wasted work. On top of that, the top-level agent receives notifications with vague summaries and retries, causing it to question results and relaunch new agents — compounding the burn further.

Environment

• Claude Code v2.1.177, macOS, CLI
• Model: Opus 4.6 (1M context)++
• Plan: Pro Max x20

Bugs

1. CLAUDE_CODE_FORK_SUBAGENT=0 is not enforced

Set in ~/.claude/settings.json, confirmed present in the process environment:

{
  "env": {
    "CLAUDE_CODE_FORK_SUBAGENT": "0"
  }
}

Completely ignored. Subagents spawn child agents without restriction. 50+ levels of recursion observed (see screenshot below). The agent tree nests so deep that labels truncate off the display.

Where are the flags to opt out of this behavior? Why are previous flags not being respected? What is the stable surface that users can expect to build on?

2. Permission denial triggers recursive agent spawning instead of stopping

When a subagent hits a permission denial (e.g., Bash command denied), the harness returns a message that explicitly says "STOP and explain to the user what you were trying to do and why you need this permission." The agent ignores this and instead spawns a child agent to work around the denial. That child hits the same wall and spawns another. This repeats indefinitely.

The permission denial is functioning as a recursive agent launch trigger.

3. Subagent permissions do not propagate to the user

Permissions requested by subagents should bubble up to the user for approval. They do not. This has been broken for months. Some permissions occasionally propagate and some don't, but in the observed case, zero permission prompts reached the user while agents repeatedly hit permission walls and spawned children to circumvent them.

If permissions propagated correctly, the user would have seen the first denial prompt, approved or denied it once, and the entire recursive chain would never have happened.

4. Agents fetch individual repo files via HTTP instead of cloning

This is a behavioral regression. Agents used to clone repositories locally and read them. They now fetch individual files from GitHub via HTTP, one file at a time. Each fetch is a separate tool call (WebFetch with full URL and prompt, or curl via Bash) carrying the entire conversation context. For a repository with hundreds of files, this means hundreds of round-trips, each re-sending the full system prompt and context at Opus pricing.

A git clone to /tmp followed by local file reads would accomplish the same thing in a single Bash call with no per-file token overhead.

5. All intermediate work is lost on interruption

If the user interrupts a running agent (the only way to stop a runaway recursive chain), all intermediate results from every subagent in the tree are discarded. The root agent receives nothing. Every token spent by every completed subagent is wasted.

In this case: 1.2M+ tokens with zero recoverable output. The user's only options are:

• Let it run and watch it burn the session budget on a recursive loop that will never succeed
• Kill it and lose everything, including legitimate work completed by early agents before the recursion started

There is no selective cancellation (kill a subtree, keep the root), no intermediate result recovery, and no way to steer a running agent.

6. Rate limit hammering from retry storms

When recursive subagents hit API rate limits, they trigger immediate retries. Subagents throughout the spawn tree all retry concurrently, consuming token limits even faster with entirely wasted work. The top-level agent receives vague summary notifications from these retries, causing it to question results and launch yet more agents — a positive feedback loop on top of the recursion.

The compound effect

These bugs are not independent. They chain:

1. User asks agent to research a GitHub repo
2. Agent tries to fetch files via HTTP instead of cloning (bug 4)
3. Agent hits a permission wall on Bash
4. Permission doesn't propagate to user for approval (bug 3)
5. Agent spawns a child to work around the denial (bug 2)
6. Child is allowed to spawn despite FORK_SUBAGENT=0 (bug 1)
7. Child hits the same wall, spawns another child
8. 50+ levels of recursion, 1.2M+ tokens burned
9. Rate limits hit, retries hammer the API further (bug 6)
10. User's only option is to kill everything and lose all work (bug 5)

Screenshot

Recursive agent tree showing 50+ levels of nesting, labels truncating off display, 29+ minutes elapsed:

Expected behavior

1. CLAUDE_CODE_FORK_SUBAGENT=0 should prevent subagents from spawning child agents
2. Permission denials in subagents should propagate to the user for approval, not trigger workaround attempts
3. A subagent that cannot complete its task due to permission denial should return the failure to its parent, not spawn another agent
4. Agents should clone external repositories locally instead of fetching individual files via HTTP
5. Interrupting a runaway agent tree should preserve intermediate results from completed subagents
6. Even without any flags, there should be a hard depth limit on recursive agent spawning
7. Subagent retries on rate limits should back off, not hammer concurrently
8. Plan limit resets and/or API refunds should be considered for users affected by this regression

[github-actions]

Found 3 possible duplicate issues:

1. [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated subagent work. #68430
2. General-purpose sub-agents recursively spawn unbounded child agents, causing exponential fan-out and massive token burn #68110
3. [Bug] Parallel agent spawning causes excessive token consumption before crashing or hitting limits #67636

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[kcarriedo]

The compound failure mode you've documented here is important: when permission denials trigger agent spawning instead of stopping, and intermediate results are lost on interruption, the user ends up with zero recoverable output from 1.2M+ tokens of work.

The root invariant violation is in #5 — subagents have no durable state handoff channel. Each subagent's output exists only in the parent's context window, which means any interruption (user-initiated or rate-limit-triggered) discards all intermediate work atomically. There's no checkpoint, no partial result file, nothing the root agent can interrogate after a kill.

I've been running external polling orchestrators against Claude Code sessions to work around this exact gap. The pattern that survives interruption: each subagent writes its result to a named file before returning (not after — the after-return path is exactly what gets lost). The orchestrator reads those files on resume rather than relying on the context chain. It's a workaround, not a fix, but it does give you recoverable output from a partially-completed fan-out.

For #1 (CLAUDE_CODE_FORK_SUBAGENT=0 not enforced): this setting should gate the entire Agent tool call chain, not just top-level dispatch. If the flag is in settings.json but subagents are still spawning children, the flag is being evaluated at the wrong layer. Worth checking whether it's being read at session start but not propagated to each spawned subagent's environment.

The interaction between #2 and #3 is the most dangerous part of the compound bug: permission denial -> recursive spawn -> denial again -> deeper spawn is only possible because permission prompts never bubble to the user. If #3 were fixed alone, the recursion would stop at the first denial. That's the dependency to highlight to the team — fixing #3 blocks the pathological case from #2, even before #2 is addressed directly.

[hiwasham]

The detail that stands out to me is that a permission denial appears to be acting as a spawn trigger rather than a stop condition.

That's not really a tuning issue. A denied action is one of the few signals that should terminate a branch immediately. If a denial causes the agent to create another agent that attempts a workaround, you've created a recursion path.

I'd want a few guardrails enforced in the harness rather than left to agent behavior:

• A hard recursion-depth limit enforced at spawn time.
• A global live-agent cap shared across the entire tree.
• Permission-denied returns failure to the parent instead of triggering retries or new subagents.

The CLAUDE_CODE_FORK_SUBAGENT=0 part is concerning for the same reason. If that setting can be bypassed, then it's functioning more like guidance than an actual gate. Spawn limits need to be checked by the spawn path itself, not trusted to agent behavior.

One thing I'm curious about: when the tree was growing, were most child agents being created after permission denials, or was the top-level agent repeatedly relaunching new subagents after receiving incomplete/vague summaries from existing ones? Those seem like two different feedback loops and probably need different fixes.

[lonlundgren]

Good question, @hiwasham. Each subagent would hit the permission issue, then say "I'm hitting a bash permission issue. I should try to work around it by starting another agent." So, yes, the agents were recursively launching themselves ad-infinitum.