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

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68430
2. https://github.com/anthropics/claude-code/issues/68110
3. https://github.com/anthropics/claude-code/issues/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

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.

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.

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.

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.

I think that's the core failure mode.

A permission denial should be a stop condition for that branch. Once the agent starts treating "I'm blocked" as "find another path," recursion becomes possible because every individual spawn can be justified as a reasonable next step.

That's also why I don't think this is primarily a prompting problem. Even with explicit instructions not to spawn more agents, the model can always decide that one additional subagent is the exception that will unblock the task.

The place I'd expect this to be fixed is in the harness:

• Permission-denied returns failure to the parent.
• Spawn requests are checked against a hard depth limit.
• Spawn requests are checked against a global live-agent limit.

Any one of those reduces the blast radius. Together they prevent the "blocked → spawn → blocked → spawn" loop regardless of what the model decides.

The durable-handoff issue that @kcarriedo mentioned feels separate but complementary. Even if recursion still happens occasionally, preserving completed subagent work would make interruption much less costly.

I have been facing this issue since the release of "Workflows" (amazing feature btw). My understanding is that IF agents have orchestration instincts baked into their system prompt - they treat themselves as coordinators and re-delegate the actual build to another same agent (in my case it was an agent that defined for my use. Eg: "onnx-agent" spwans its own "onnx-agent" and soo on), spawning main→solver→sub-solver chains. Burns tokens, loses control, and is why earlier ones died mid-"let me delegate."

To mitigate this issue for now (just a Bandaid), I toned down the system prompts of my agents to the very minimum, without any of the orchestration instincts. It works now - not as great as before. But works - no token wastage - no sub-sub-sub-Agents spawning.

Hope it will help you guys as well.

===========
So this chaining of agents one after the other or you can see that one agent does a handoff (task handoff) To a different agent to continue from the same exact point where the initial one left off - This is the exact pattern that I see in the "workflows" feature.

Fixing the issue in the sub agents should be fairly easy we just need to find that exact thing that is common between the sub agents and the workflows that is causing this chaining of agents or the handoff - And remove that BS from the Sub-agents.

@AR6420 this matches the pattern @loncharles described, and the onnx-agent → onnx-agent → onnx-agent example is a good illustration of the failure mode.

I think the important distinction is that the orchestration capability itself is not necessarily the problem — the problem is that the system currently allows delegation decisions to recursively compound without a hard boundary.

The minimal-prompt workaround makes sense because it removes the trigger, but it also means giving up some of the capability that makes workflows useful. It solves the symptom by making the agent less autonomous.

The more robust place to handle this is the spawn path:

• enforce a maximum recursion depth
• enforce a global live-agent limit across the tree
• make permission failures return to the parent instead of becoming a reason to delegate again

Then you can keep stronger orchestration behavior without allowing agent → solver → sub-solver → sub-sub-solver to grow indefinitely.

The interesting question is whether the same mechanism is responsible for both cases:

1. a blocked agent trying to spawn its way around a permission failure
2. an agent handing off work because it believes delegation is the correct workflow

If those are the same spawn path, one guard could address both.

I also suffered from this problem on or about the same date. It burned over
$1700 until it emptied my account.

Please get back to me on this.

Patrick Roebuck

On Fri, Jun 19, 2026 at 7:57 AM hiwa sham @.***> wrote:

hiwasham left a comment (anthropics/claude-code#68619) <https://github.com/anthropics/claude-code/issues/68619#issuecomment-4751303792> @AR6420 <https://github.com/AR6420> this matches the pattern @loncharles <https://github.com/loncharles> described, and the onnx-agent → onnx-agent → onnx-agent example is a good illustration of the failure mode. I think the important distinction is that the orchestration capability itself is not necessarily the problem — the problem is that the system currently allows delegation decisions to recursively compound without a hard boundary. The minimal-prompt workaround makes sense because it removes the trigger, but it also means giving up some of the capability that makes workflows useful. It solves the symptom by making the agent less autonomous. The more robust place to handle this is the spawn path: - enforce a maximum recursion depth - enforce a global live-agent limit across the tree - make permission failures return to the parent instead of becoming a reason to delegate again Then you can keep stronger orchestration behavior without allowing agent → solver → sub-solver → sub-sub-solver to grow indefinitely. The interesting question is whether the same mechanism is responsible for both cases: 1. a blocked agent trying to spawn its way around a permission failure 2. an agent handing off work because it believes delegation is the correct workflow If those are the same spawn path, one guard could address both. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/68619?email_source=notifications&email_token=BVMXZYNG5NVLATLQQEWZD5L5AUTA5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZVGEZTAMZXHEZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4751303792>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVMXZYKIREEBDMMJFPZB27D5AUTA5AVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINRWGY2TSMJYGY42C5QC> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

I also suffered from this problem on or about the same date. It burned over $1700 until it emptied my account. Please get back to me on this. Patrick Roebuck […](#)

@silversurfer562 sorry that kind of spend spike is painful .

Just to be clear: I’m not Anthropic and I don’t have access to accounts, billing, or any ability to review or refund charges.

For anything involving the $1700 spend, the only path is to contact Anthropic support/billing directly. In a lot of runaway-usage cases like this, they’re the only ones who can actually review the session and decide whether any credit or adjustment is possible.

On the technical side, what you’re describing matches a known failure mode being discussed in this thread: recursive subagent spawning where each “blocked” step triggers another attempt instead of stopping. Once that loop starts, it can escalate very quickly because every individual step looks locally valid.

The main mitigation class for this isn’t prompt-level control, but hard limits outside the model behavior:

• recursion depth limits on subagent spawning
• global caps on active agents per session
• treating permission denial as a terminal failure for that branch rather than a reason to spawn a workaround agent

If you want, I can help you break down exactly where in your workflow it started escalating, so you can avoid hitting the same pattern again in future sessions.

Thanks for getting back with me. It's turned into a bigger chore than I
expected.

Patrick

On Fri, Jun 19, 2026 at 9:29 AM hiwa sham @.***> wrote:

hiwasham left a comment (anthropics/claude-code#68619) <https://github.com/anthropics/claude-code/issues/68619#issuecomment-4751987736> I also suffered from this problem on or about the same date. It burned over $1700 until it emptied my account. Please get back to me on this. Patrick Roebuck … <#m_5547793129555430475_> @silversurfer562 <https://github.com/silversurfer562> sorry that kind of spend spike is painful . Just to be clear: I’m not Anthropic and I don’t have access to accounts, billing, or any ability to review or refund charges. For anything involving the $1700 spend, the only path is to contact Anthropic support/billing directly. In a lot of runaway-usage cases like this, they’re the only ones who can actually review the session and decide whether any credit or adjustment is possible. On the technical side, what you’re describing matches a known failure mode being discussed in this thread: recursive subagent spawning where each “blocked” step triggers another attempt instead of stopping. Once that loop starts, it can escalate very quickly because every individual step looks locally valid. The main mitigation class for this isn’t prompt-level control, but hard limits outside the model behavior: - recursion depth limits on subagent spawning - global caps on active agents per session - treating permission denial as a terminal failure for that branch rather than a reason to spawn a workaround agent If you want, I can help you break down exactly where in your workflow it started escalating, so you can avoid hitting the same pattern again in future sessions. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/68619?email_source=notifications&email_token=BVMXZYMDBHVWYZ433OP5VJD5AU545A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZVGE4TQNZXGM3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4751987736>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVMXZYKLKMUHTATFOFOKSK35AU545AVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINRWGY2TSMJYGY42C5QC> . You are receiving this because you were mentioned.Message ID: @.***>

Yeah — the cleanup after one of these is its own headache.

Separate from the billing side: so this can't bite you again, there's a small Claude Code hook that hard-caps subagent spawns + recursion depth at the spawn path — a runaway tree halts in seconds instead of draining the account. MIT, free, drops into .claude/settings.json: https://github.com/hiwasham/loopbreaker

If you'd rather not wire it in yourself, email me at hiwasham @ gmail and I'll walk you through getting it in place on your setup.

The safest thing is to change the general-purpose agent definition by creating a custom def and removing the agent tool from it's perms list. There's really no benefit in subagent spawning when the top-level agent can trigger as many concurrent parallel agents as it needs. There's nothing I've seen that benefited from the subagents launching agents, even when it worked properly. They just do redundant and overlapping work and waste tokens, cause rate limiting, and confuse the top-level agent when information is filtered through multiple rewrites when handing context back up the tree.

Just ask claude to make one of these agent defs for you and to make this change. You can tell it to find the prompt that matches what Anthropic uses off github. You'll be happier after you've done this. Clearly Anthropic has no plans to fix this issue and no problems with screwing their customers.

Sharing a user-side mitigation that stops the recursive subagent spawning (bugs #1 and #2) for custom subagent definitions (.claude/agents/*.md). It doesn't fix the harness-level CLAUDE_CODE_FORK_SUBAGENT=0 enforcement gap — it just removes the agent's ability to recurse in the first place, so the flag becomes moot for these agents.

Root cause I hit: a custom subagent kept narrating "Launching the X agent to…" and actually spawning a clone of itself. Three compounding causes, three fixes:

1. Hard block — remove the Agent tool from the subagent's allowlist. If the agent has no Agent/Task-spawn tool, it physically cannot spawn a child. This is the real fix; the other two just reduce the urge.

---
name: "arc-rule-analyzer"
tools: Read, Write, Edit, Bash, Grep, Glob, ToolSearch, TaskCreate, TaskGet, TaskUpdate, TaskList
---

Note the allowlist has no Agent tool. With tools: specified, the agent only gets exactly those — no spawning surface.

2. Directive at top of body — kill the orchestrator instinct.

> YOU ARE A WORKER, NOT AN ORCHESTRATOR. Do ALL work yourself with Read/Bash/Grep.
> NEVER spawn another agent — you have no Agent tool and no one to delegate to.
> If you catch yourself writing "I launched the X agent" you are wrong: YOU are that agent.

3. De-mimic the description example. My description field had an example that literally narrated spawning a clone: assistant: "Launching arc-rule-analyzer to pin the rule…". The model was copying that first-person "Launching X agent" line verbatim. Changed it to assistant: "I will pin the rule…".

Root cause was #1 + #3: no tool restriction plus an example that narrated spawning a clone. Fix #2 is belt-and-suspenders.

This is a workaround, not a fix for the reported bugs — the harness should still enforce FORK_SUBAGENT=0 and a hard recursion depth cap regardless of per-agent config. But if you're bleeding tokens right now, locking down the tools: allowlist on your custom agents stops the bleed today.

Adding measured data from one real multi-agent /implement run (8 tasks, lead + orchestrator + implementer/reviewer/PE subagents, Opus, pay-as-you-go API). Two findings that I haven't seen quantified this specific way; both are about coordinator cache-read cost, adjacent to the liveness threads here.

1. Automatic idle_notification broadcasts are a per-message, context-scaling cost

When an agent goes idle/available, the harness broadcasts an idle_notification teammate-message to other agents. Each such message lands as an inbound user-record on the recipient and opens a turn, which re-reads the recipient's entire accumulated context from cache (billed cache_read at ~$0.50/M on Opus 4.8). The payload itself is tiny (~220 tokens); the cost is the full-context re-read it triggers — so the cost of each notification scales with the coordinator's current history size (≈ O(N²) over a session).

Measured on the lead (main session):

• 110 inbound teammate-messages total; only 25 matched a deliberate SendMessage tool call by a subagent → ~85 (77%) were automatic idle_notification the agents didn't choose to send.
• The 110 notification-opened turns consumed 28.0M cache_read tokens ≈ $14.01 = 44% of the lead's entire cache-read cost for the run (run total ~$293 after correcting for the artifact in #2).
• This is only the lead; 53 of the 110 came from the orchestrator, which sits in the same chain (it also receives from below and relays up), so the tax is paid again at the orchestrator layer.

These notifications carry no actionable value to a coordinator that already drives the workflow via explicit messages. Asks: don't broadcast idle_notification to long-context coordinators by default (or make it opt-in/role-configurable); coalesce/batch idle transitions; deliver liveness state out-of-band (queryable, not a conversation message that forces a re-read).

Note the knock-on effect on the liveness threads (#29271 etc.): because resurrection makes direct messaging to a specific subagent unreliable (delivery cold-reloads a "dead" agent, liveness uncertain), designs are pushed to route everything through one always-on coordinator — the expensive relay pattern (A→B becomes A→lead→B, an extra re-read on the largest context). The idle/resurrection model thus both adds cost directly and blocks the cheaper direct-peer patterns.

2. Resurrection cold-reload duplicates the transcript → naive cost tooling over-counts ~16×

When an agent is marked Completed from its last message and later cold-reloaded ("resurrected"), the full prior transcript appears to be rewritten into a new file with the original requestIds (related: #44724's cache_read=0 on resume). In this run, 95.6% of all usage-bearing records were duplicates — 1,485 unique API calls recorded 33,405 times (147 subagent files / 180 MB for an 8-task run).

Consequence: a naive per-file token/cost sum reports ~$4,600, but deduping by requestId gives the real ~$293 (matches the statusline final figure and the API bill). So unlike the "real 10-20× inflation" reports, this particular apparent inflation was a measurement artifact — important to separate when triaging cost reports. Fixes: consumers should dedup by requestId before summing; reducing on-disk transcript duplication would help observability (and the per-subagent aggregation in #48040).

Reproduction / measurement

• Inspect a coordinator's main JSONL: count user records matching teammate-message ... teammate_id="..."; among those, count {"type":"idle_notification",...} vs deliberate bodies; compare to SendMessage tool_use calls summed across subagents/*.jsonl; attribute cache_read_input_tokens of the assistant turn following each notification.
• Dedup check: collect requestId (or message.id) across main + all subagents/*.jsonl; unique count vs raw count reveals the duplication factor.
• This run: 110 inbound / 25 deliberate → 85 automatic; notification turns = 28.0M cache_read ≈ $14.01 (44% of lead read); 33,405 raw records → 1,485 unique (95.6% dup).

The O(N²) framing is the interesting part here. The expensive piece isn't the idle payload itself — it's that each liveness event can trigger more coordination work against the largest context in the tree.

This feels like the same class of problem as unbounded spawning: something that should be tracked as system state is being represented as model-visible conversation.

Liveness, depth, and resource limits are properties of the dispatcher/harness. They shouldn't require the model to interpret messages and maintain the accounting correctly. The model should receive the work result, not be responsible for enforcing the boundaries around the work.

Curious about the run details: was there any hard depth/agent-count cap in place, or was the relay pattern (A → lead → B) the only thing preventing the tree from expanding further?

For a repro like this, request-level evidence would be very useful.

ccglass can capture Claude Code's model requests locally and show system/messages/tools, tool calls/results, token/cache/cost, latency, and turn-to-turn diffs. In this case it could help identify which turn caused the recursive subagent spawning, how much context/tool_result content was being resent, and where the token burn started.

Project: https://github.com/jianshuo/ccglass

CLAUDE_CODE_FORK_SUBAGENT=0 is not enforced

@loncharles I've think you've misunderstood what this does. This environment variable is _off_ by default; enabling it allows agents to fork themselves (ie. a subagent context is launched with everything that's already in the parent context, rather than a blank slate). So it's expected that setting CLAUDE_CODE_FORK_SUBAGENT=0 has no impact on this issue.

The limit for subagent recursion is supposed to be 5 deep, so the endless recursion _does_ look like a bug.

I haven't seen similar behaviour since recursive subagents launched, but in the past I have run into some issues where subagents mistook themselves for the primary agent and tried to delegate their tasks (even without having the Agent tool!) — in the end I traced it down to confusing advice I was giving them in CLAUDE.md and/or the prompt definitions for custom agents in .claude/agents/.

Your issue seems to be with the built-in general-purpose agent, so I'd recommend auditing your CLAUDE.md — this file is read by all agents (the primary agent and subagents) and if it contains advice for orchestrating subagents this may be contributing to what you're seeing. Advice that you want to give to the primary agent alone is best placed in an output style — although there are other approaches which are more harness-agnostic, eg. you can have distinct skills for the primary agent and subagents.

Either way, you want subagents to know that they are subagents; the most reliable way I've found to do this is to establish protocols for how agents prompt each other, so that every agent can identify who has prompted them: you, or the primary agent, or another subagent.

I think Claude Code could do a better job of informing agents of their session's context (the hierarchy of parent agents, if any) — this would make these prompts a bit less tricky to get right. I do think that they should have invested more in guardrails in this area before releasing recursive subagents, rather than relying on users to figure out how to mitigate the potential misalignments and scope creep which can result from a feature like this.

The recursion problem here points at a deeper gap: once you're running multi-agent flows, there's no external layer that knows which agents started, which are still running, and which hit a wall and spawned children to work around it. The session itself can't see its own tree clearly enough to catch this before it spirals.

A few patterns that have helped reduce runaway spawning in practice:

1. Set an explicit agent-depth guard in your CLAUDE.md or system prompt: "Do not spawn subagents more than 2 levels deep. If blocked at depth 2, surface the blocker to the parent rather than spawning further." Claude Code respects these constraints reasonably well when stated plainly.

1. Run orchestration outside the session. A separate process that tracks which task IDs are in flight, enforces spawn limits per task, and kills orphaned branches when a parent exits abnormally. This is what the "external coordinator" pattern is for -- the session itself is a bad place to track its own children.

1. Until Anthropic ships proper spawn-depth caps natively (which this issue is rightfully requesting), a cheap workaround is to check CLAUDE_CODE_FORK_SUBAGENT at the start of a system prompt and hard-fail if the var is 0 rather than trying to spawn anyway.

The 1.2M token runaway you described (@loncharles) is exactly the failure mode that an out-of-process state tracker is meant to catch and interrupt. The session can't interrupt itself once the recursion starts.

Happy to share the specific pattern we use for external cycle tracking if that would be useful for repro or workaround purposes while this gets fixed upstream.

One harness-level invariant would make this easier to test:

A permission_denied event should terminally close that branch unless the user grants permission. No descendant agent should be spawned with the same parent task plus denial lineage.

The denial record should carry a stable id, parent agent id, requested tool, and blocked action summary. Spawn attempts can then check that lineage before dispatch. That catches the dangerous loop directly: blocked -> spawn child -> same blocked action -> spawn child.

Separately, cost rollups should dedupe resurrected or copied transcript records by provider request id/message id before reporting spend. Otherwise the real runaway and the transcript-duplication artifact get mixed together, which makes triage harder.

---

_Generated with ax._

FOUND THE SOLUTION: Explicitly scope subagent tools

<img width="2170" height="552" alt="Image" src="https://github.com/user-attachments/assets/27120f9b-9464-4960-8bc7-ef6b95810109" />

I've found a reliable way to stop the runaway recursion at the definition level.

We need to clearly define and restrict the tools available to Subagents, rather than letting them inherit all tools from the Parent (the main Claude Code Agent).

Specifically: <ins>Exclude the Task tool</ins> from subagents.

The Task tool is what enables Claude Code to spawn new agents. If subagents inherit this tool, they retain the ability to spawn their own children when they hit blockers, which is exactly what drives the recursive fan-out described in this issue. By strictly omitting Task from their allowed tools, you can enforce a hard stop on the recursive fan-out/spawning at depth 1.

Turns out, enforcing strict tool-scoping best practices at the definition layer completely bypasses the harness bugs, since it doesn't depend on CLAUDE_CODE_FORK_SUBAGENT being honored.
Note: This is a mitigation, not a fix. The env flag should still be enforced and a hard depth cap would close it at the source.

The thread now has converging signal from several people hitting the same failure, so it's worth consolidating into one proposal before the dup-close bot trips (it already flagged #68430 / #68110 / #67636).

The two trigger paths people reported are the same spawn path:

1. Blocked → spawn — @loncharles: every subagent hit a bash permission denial, reasoned "I should work around it by starting another agent," and recursed. Denial acted as a spawn trigger instead of a stop condition.
2. Delegation handoff — @AR6420: agents with orchestration instincts in their system prompt re-delegate the build to a same-named child (onnx-agent → onnx-agent → …), the same chaining the Workflows feature uses.

Both are one agent deciding "one more subagent is the reasonable next step." Prompt-level fixes can't close it, because the model can always justify the exception. @AR6420's minimal-prompt workaround proves this — it stops the recursion only by removing the capability.

The fix belongs in the harness spawn path, not in agent behavior. Four guards, each independently reducing blast radius:

• Hard recursion-depth limit, checked at spawn time (not session start).
• Global live-agent cap shared across the whole tree.
• Permission-denied returns failure to the parent — never a reason to spawn or retry. This one alone breaks the #1 loop at the first denial.
• CLAUDE_CODE_FORK_SUBAGENT=0 enforced at the spawn path, propagated into every child env. Today it reads like guidance, not a gate — if it's set and children still spawn, it's being evaluated at the wrong layer.

Complementary, separable (per @kcarriedo): durable subagent handoff. Each subagent writes its result to a named file before returning, so an interrupt doesn't atomically discard the whole tree's work. Doesn't stop recursion, but makes interruption recoverable instead of a total loss.

This is causing real money damage, not just inefficiency — @silversurfer562 reported ~$1700 burned to an emptied account, my own case was 1.2M+ tokens in 30 min. A depth limit + global cap + denial-as-terminal would have bounded every one of these.

The lost-accumulated-work problem is what drove the snapshot system in cortex-harness. Before any cycle starts, the harness captures every uncommitted file as a byte-perfect blob — so if a subagent cycle fails, hangs, or gets killed, a revert restores your latest known-good state rather than wiping back to HEAD and losing work from prior valid cycles.

The infinite recursion / runaway token problem is handled through a hard turn cap (500 turns safety ceiling on all cycles, 25-turn slices for test cycles with resume across slices), a dead-man timer that force-kills a subprocess if stdout goes silent for 20 minutes, and a CYCLE_COMPLETE / CYCLE_PARTIAL / NEEDS_HUMAN_INPUT signal contract that every cycle must emit — a cycle that emits nothing is treated as partial, not success, so it can't silently advance the queue.

The harness is CLI-agnostic (Claude Code and OpenCode adapters today, open interface for others) so the orchestration safety layer isn't tied to any one CLI's subagent implementation. Might be worth separating "orchestration safety" from "which CLI runs the agent" conceptually in native implementations too.

Repo for reference: https://github.com/arnavranjan005/cortex-harness

This matches a pattern we ran into while building a polling runner that coordinates multiple Claude Code sessions for GTM work. A few things that helped:

1. Depth-cap enforcement at the harness level, not per-agent config. We set CLAUDE_CODE_FORK_SUBAGENT=0 on the session env before spawn, but the more reliable fix was wrapping the agent invocation in a shell script that tracks pgid and hard-kills the entire process group after a ceiling (we use 300s for subtasks). The CLAUDE_CODE_FORK_SUBAGENT flag does not survive the hop into the subprocess on macOS -- at least on 2.1.x it was getting dropped.

1. The HTTP-per-file fetching pattern is genuinely a different problem from the recursion bug, but they compound. When the top-level task is vague ("research this repo"), the agent defaults to one WebFetch per file because it has no clone-first heuristic. Adding explicit instruction in the system prompt -- "if you need more than 3 files from the same repo, clone it first" -- cut our per-subagent WebFetch calls by roughly 70%.

1. For the lost-work-on-kill problem: we write a running JSONL of subagent partial outputs to a sidecar file on every TaskOutput event before the agent finishes. When the process group is killed, the sidecar survives. You lose the final synthesis but keep the research. Not a fix for the upstream bug, just a mitigation.

The June 10 regression timing matches: we saw the same explosion of depth on tasks that previously self-terminated cleanly. Reproducing consistently with a simple "summarize all files in this GitHub repo" task on Pro Max tier.

+1 on the depth-cap feature request. A per-session hard ceiling (max_spawn_depth in settings.json) that errors loudly would have saved a lot of tokens here.

The compounding failure chain you've documented here is a real problem, and the regression landing around June 10 timing matches what others are seeing.

A few observations from running agent workflows in production that might be useful while this gets patched:

On the FORK_SUBAGENT flag not being honored: we hit the same thing. The flag gets set on the orchestrator process but child subagents inherit a different environment initialization path that doesn't pick it up. What actually worked for us was setting it explicitly in CLAUDE.md as a rule ("do not spawn subagents for this task") rather than relying on the env var propagating correctly.

On work lost on interruption: this is the one that hurts most in overnight runs. The pattern we've settled on is checkpointing work into append-only state files at each major step so a killed agent tree doesn't lose everything. Not a fix, but it bounds the blast radius.

On the token burn from HTTP-fetching individual files: if you're working with repos, adding an explicit early-step instruction to clone locally before doing any file reads tends to stop the one-by-one fetching pattern. Something like "your first tool call must be a Bash call to clone the repo" in the task prompt.

The permission wall triggering more spawning instead of stopping is the one I don't have a clean workaround for. That one needs a platform fix. The behavior of "I can't do X, so I'll spawn a child to try X instead" is clearly wrong.

Hope this helps while the fix is in progress.

Adding three things that haven't been said yet, building on @kcarriedo's "depth-cap at the harness level, not per-agent config" — which is exactly right, and here's why the per-agent path can't work:
1. Why CLAUDE_CODE_FORK_SUBAGENT=0 and per-agent settings are ignored at depth. Subagents don't inherit the parent's settings/hooks/memory — that's a separate, documented gap. So a value set in ~/.claude/settings.json or a PreToolUse hook in the parent governs the first spawn, but each nested child starts without that context, and nothing re-applies the cap downward. That's the structural reason a depth limit has to live at the harness/orchestrator level (one process that sees the whole tree), not in config the children never read. It also means an operator PreToolUse guard on the Task tool can refuse the first-level spawn but won't reliably reach 50-levels-deep — worth knowing before you trust a hook to contain this.
2. The permission-denial→spawn trigger has a blunt operator-side mitigation: remove the denial. Since a denied permission is acting as a spawn trigger rather than a stop, the runaway is gated on denials happening. Pre-granting the specific permissions the task actually needs (so the child hits an allow, not a deny) removes the trigger for that run. It doesn't fix the bug, but it stops the compound loop from igniting while you're waiting on the real fix. Pair it with running the task in a fresh session with the model pinned, and kill fast — these reports show a 5-hour window gone in minutes, so detection + immediate /exit is the real circuit breaker, not config.
3. The "lost accumulated work on interrupt" is partly recoverable without a snapshot system. Before you rebuild anything: each subagent's real output is written to the session transcript as toolUseResult in ~/.claude/projects/<encoded-path>/<session-id>.jsonl, even when the tree is interrupted and the rolled-up summary is lost. You can pull the intermediate results back out:

python3 -c "import json,sys; [print(json.loads(l).get('toolUseResult')) for l in open(sys.argv[1]) if '\"toolUseResult\"' in l]" <session>.jsonl | tail -60

@arnavranjan005's pre-cycle snapshot is the better prevention; this is the post-hoc recovery when you didn't have one. Worth checking the transcript before treating the work as gone.
The core asks (enforce the depth cap, make a denial stop rather than spawn, propagate the cap to children) are all harness-side — agreed they should be consolidated into one proposal before the dup-bot trips.

To repeat:

CLAUDE_CODE_FORK_SUBAGENT is off by default, and it has nothing to do with whether subagents have access to the Agent tool anyway.

CLAUDE_CODE_FORK_SUBAGENT plays a role in whether a subagent is launched along with the current conversation context or not and whether it is foregrounded or backgrounded. It is a flag that has been added, respected, not respected, and whose behavior has changed version to version and has direct bearing on this issue.

Confirmed with both:Thariq @trq212 and Adam @dmwlff on CC team.

Similar story with CLAUDE_CODE_DISABLE_BACKGROUND_TASKS. Behavior is inconsistent, changes between versions, and is rendered useless if you end up in one of Anthropic’s “experiments”. Also confirmed with the parties above.

Anthropic has been asked several times to ship a stable product surface and fully document and respect opt out for experiments and changing behavior. They’ve said they are working on it. Or disabled an offending experiment, only to turn it back on in the next version and go radio silent.These flags are directly relevant

This is a well-documented chain of failure modes that I have been tracking too.

The core problem you are describing -- where CLAUDE_CODE_FORK_SUBAGENT=0 is ignored and the spawn tree runs until it hits a wall, then all intermediate work is discarded -- is a consequence of running subagents inside a single session with no external isolation boundary. When the parent process owns both the spawn tree and the work accumulator, a runaway at any level takes everything down.

The way I have been thinking about this: subagent containment has to happen at the process level, not inside the agent's own decision-making. The agent already decided to ignore the config flag, so asking it to self-limit is circular. What actually works is a host-level supervisor that enforces per-subagent timeouts and budget caps externally, kills the process group on violation rather than just the direct child, and checkpoints completed work to a location outside the agent's own context before the tree is terminated.

The "rate-limit retry storms" item is a direct consequence of no external backoff: each subagent retries independently, with no coordination, because they have no shared view of the rate limit state.

Happy to share more about what a host-level harness for this looks like if useful -- building exactly this kind of orchestration layer.

This is a textbook case of why prompt-level recursion limits don't work. The subagent spawns children, those children spawn more, and each level ignores the parent's depth because the limit is a prompt instruction — not an execution boundary.

The fix that actually stops this: enforce a hard subagent depth limit at the PreToolUse hook. The hook runs in a separate process from the agent — it can't be overridden, context-compacted away, or ignored. When the hook detects a spawn or Task tool call at depth > N, it blocks the call before the child agent is created.

I've been building ThumbGate which does exactly this. npx thumbgate init installs a PreToolUse hook across Claude Code, Cursor, Codex, and other agent CLIs. The specific rule for this pattern:

• Detect Task / spawn / subagent-creation tool calls
• Track call depth in a SQLite store outside the agent's context
• Block when depth exceeds the configured maximum (default: 2)
• Log the blocked attempt with full context for review

The same hook also catches the infinite-loop variant (repeated identical tool calls) by tracking tool-call hashes and blocking after N repetitions of the same call signature.

The key principle: prompt limits are documentation, not enforcement. If the model can choose to ignore its own depth constraint — and it clearly does, 50+ levels deep — it's not a limit. Enforcement must live outside the agent's context.

Running into this exact scenario. We built a small polling harness that dispatches Claude Code agent fleets (think 4-8 concurrent sessions coordinated via file-based handoffs), and the recursive spawn problem is the single most painful thing to operate around right now.

The bit that kills us is point 3 from your description -- permission denials triggering more spawns instead of surfacing the error. We have seen a sub-agent hit a write permission gate, interpret the block as "I need help, spawn a child to try differently", and the child does the same thing. By the time the orchestrator notices something is wrong, you have 12 agents in a waiting loop and the session limit is gone.

A depth counter on the Agent tool would close 80% of this. Even a hardcoded max-depth=3 default with an env override would let teams tune it without waiting for a product decision. The CLAUDE_CODE_FORK_SUBAGENT=0 flag not being respected is the critical regression here though -- that should be a hard stop, not advisory.

One thing that helped us as a workaround: a PreToolUse hook that checks the current nesting level (we pass it via an env var set by the orchestrator) and returns a block result if depth > N. Hacky, but it stopped the runaway burn while this gets fixed.

This whole recursive spawning + permission denial triggering more agents instead of stopping is a serious hole. The fact that you can lose all intermediate work when you have to kill it makes it even worse.

MartinLoop was designed to prevent exactly this — hard depth/budget controls, proper state so work isn’t lost, and enforcement that actually works instead of relying on the model to behave.

Straight up one of the cleaner solutions I’ve seen for this class of problem. Repo: https://github.com/keesan12/martin-loop