[BUG] scheduled-task sub-agents self-invoke a skill and spawn duplicate agents, multiplying token spend

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 25, 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
During an automated scheduled run of the checkin-review skill (devops-checkin-review), 5 intentionally-launched background sub-agents each independently re-invoked the checkin-review Skill themselves. That skill's instructions describe a full multi-agent orchestration workflow, so several sub-agents interpreted it as an instruction to launch their own fleet of sub-agents — resulting in 19 concurrent agents running against a task that only needed 5. Some of these duplicate agents also returned meta/status-update text instead of their assigned work on their first turn, requiring manual follow-up messages to get real output.

Environment
Claude Code CLI, scheduled task run (devops-checkin-review), non-interactive session
Orchestrator (main session) launched 5 general-purpose background agents via the Agent tool, each assigned a fixed, disjoint list of TFVC changeset IDs to review (no ambiguity in scope)
Each spawned agent had full tool access (including the Agent tool itself and Skill tool), and the checkin-review skill was listed as available to it
What happened
Orchestrator launched 5 background agents, each with an explicit, self-contained prompt listing exact changeset IDs, review criteria, and required output format (plain text, no email, no state mutation).
At least 3 of the 5 sub-agents called Skill({skill: "checkin-review"}) on their own initiative, apparently because the skill was visible in their tool list and its description ("Review new TFVC check-ins... then email the result") seemed to match their task.
The skill's instructions describe the entire multi-project scan → review → email → watermark pipeline, including guidance to fetch diffs, and (based on the resulting behavior) implicitly encouraged further delegation.
Several sub-agents then launched their own child agents to "help" cover the work, some duplicating the exact same changeset ranges already assigned to sibling agents. Peak concurrent agent count observed via ListAgents: 19, of which only 5 were the ones actually launched by the orchestrator.
Two of the original 5 agents returned a status/meta message on their first turn (e.g. "All 7 review agents are now running in the background... I'll wait for them to complete") instead of their own findings, requiring the orchestrator to send an explicit corrective follow-up message before they produced real output.
Three of the rogue duplicate agents ran to completion before the orchestrator noticed the fan-out (via ListAgents) and stopped the remaining 14 with TaskStop. No email was sent and no watermark file was modified by any rogue agent — the orchestrator's final consolidated pass did that after manually de-duplicating and cross-checking findings.

Suggested fixes (for consideration)
Scope tool/skill visibility for background sub-agents to what their specific task prompt requires, rather than the full session's skill list.
Have the Agent tool's spawned agents default to not re-invoking Skill for a task that was already fully specified by their prompt (i.e., prompt instructions should take precedence over an available skill's broader instructions).
Consider a hard cap (or an explicit confirmation step) on an agent's ability to spawn further sub-agents when it itself was spawned as a sub-agent (bounding fan-out depth/width by default).

What Should Happen?

Expected behavior
A sub-agent given a narrow, fully-specified task (explicit changeset list, explicit output format, explicit "no email/no state mutation" instructions) should not have visibility into — or should not act on — a Skill whose instructions describe a much broader orchestration workflow than what it was actually asked to do. At minimum, invoking a skill should not itself be treated as authorization to spawn further sub-agents when the invoking agent's own task was already fully scoped by its parent.

Error Messages/Logs

Steps to Reproduce

This occurred during a real scheduled run reviewing 43 TFVC changesets across 4 projects

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.34493.1 (255293) 2026-08-21T02:05:20.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗