[Bug] Subagent tool stripped in nested subagent calls breaks tool invocation

Confirming this independently on the same build - macOS (Darwin 25.5.0), Claude Code 2.1.217,
homebrew install. My general-purpose tool inventory matches yours exactly.

Two additional data points that narrow the cause.

1. It is not frontmatter parsing.

#80104 reports the same bug and attributes it to Agent being dropped from an explicit
frontmatter tools: list. That isn't the mechanism. I tested three request paths and all three
fail identically:

• built-in general-purpose / claude (documented as Tools: *)
• a custom agent listing Agent explicitly in tools:
• a custom agent omitting tools: entirely, so it inherits the full parent tool surface

The third case is the informative one - there is no list to mis-parse, and Agent is still
withheld. So the tool is being filtered at provisioning, not lost while resolving frontmatter
entries.

2. The error string suggests a deliberate gate, not a missing registration.

Calling Agent from inside a subagent returns:

No such tool available: Agent. Agent exists but is not enabled in this context.
Use one of the available tools instead.

ToolSearch with select:Agent separately returns No matching deferred tools found, so it
isn't merely an unloaded deferred tool either. The harness knows the tool exists and is
declining to provision it to the subagent.

Also ruled out

• Version threshold - 2.1.217 is well past the documented 2.1.172
• Local config - no disallowedTools and no relevant env var in project or user settings.json
• Session context - reproduces identically in an IDE child session

(CLAUDE_CODE_CHILD_SESSION=1) and in a fresh top-level claude -p session

One correction to scope, re #80104

That issue also reports ToolSearch being stripped from subagents. I can't reproduce that half
on macOS - every subagent I ran had ToolSearch and used it successfully (it's how they queried
select:Agent). #80104 mentions PowerShell in its tools list, so that symptom may be
Windows-specific and separable from the Agent bug described here.

Not verified

I could not test your fork finding. fork isn't dispatchable as a subagent_type in my
session - the Agent tool rejects it with Agent type 'fork' not found and lists only the
registered agent types. It appears reachable only via /subtask. Noting this so the workaround
isn't assumed to be universally available; your observation stands, I just can't add
confirmation to it.

Docs line 849 of sub-agents.md ("A fork still can't spawn another fork. It can spawn other
subagent types...") is at least consistent with what you saw.

Sharing field data that's consistent with (though not conclusive proof of) the mechanism described here — we've been trying to diagnose why /code-review (bundled skill) appears to hang for a long time with no visible progress.

Environment: Claude Code v2.1.220, macOS (darwin), same project across both incidents.

Incident 1: /code-review at large tier (should fan out to ~10 parallel finder subagents) ran for ~87 minutes with one finder subagent showing no output at all, while others completed in seconds-to-minutes. User gave up waiting and re-ran at medium tier, which completed normally.

Incident 2 (next session): /code-review with no args (defaults to a tier that should spawn 6 finder agents + a monitor agent) ran for ~1h30m with no visible progress before the user manually stopped it. Retried at low tier (which, per the skill's own prompt template, is a single-pass no-subagent review) — after ~1h13m it still appeared to be doing nothing.

Post-hoc, we inspected the session's local transcript directory. The no-args run had real subagent transcript files with activity timestamps (~20 min of activity, then nothing for the remaining ~70 min it was left running). The low-tier retry had zero subagent transcript files at all, despite low tier not being supposed to spawn subagents in the first place — so this data point doesn't confirm or rule out anything about #80036 specifically, just that something about the orchestration was stuck before producing any observable output either way.

In both cases TaskList showed no visibility into the skill-internal subagents, so there was no way to distinguish "still working" from "wedged" from the client side.

If it's useful, I can dig up more transcript excerpts (redacted of project-specific content) — this has now happened twice in the same project and effectively made /code-review at anything above low tier unusable for us; we've been falling back to codex review-diff instead, which has completed reliably both times.

Correction (2026-08-25): I withdraw the earlier conclusion that this A/B result demonstrates a Claude Code provisioning bug or a documentation/runtime mismatch. The documented rule that setting the maximum to 1 disables nested delegation is consistent with the observed adjusted budget: process raw 2 projected 1, while process raw 3 projected 2. For the intended main → custom subagent → leaf path, raw 3 is therefore the appropriate configured maximum. This is not a request for a bug fix or future-version monitoring.

The following metadata remains as a factual record from Claude Code 2.1.245 on Linux/WSL2.

I tested the same custom subagent definition, which explicitly lists the Agent tool, under two otherwise identical fresh interactive sessions:

• permission mode: auto
• fork mode disabled
• background tasks disabled
• foreground custom-subagent invocation
• no child Agent call was made; this was tool-inventory only

Case A — CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=2:

• main Claude process environment: max depth 2
• Bash launched from the main conversation reported max depth 1
• nested custom subagent Bash also reported max depth 1
• nested subagent callable tools: Read, Edit, Write, Bash, Skill, advisor
• Agent and Task were absent

Case B — CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=3:

• main Claude process environment: max depth 3
• Bash launched from the main conversation reported max depth 2
• nested custom subagent Bash also reported max depth 2
• nested subagent callable tools: Read, Edit, Write, Bash, Agent, Skill, advisor
• Agent was present; Task was absent

The fact that both Bash children observed the same adjusted value means this run did not establish a per-subagent 3 → 2 → 1 sequence. It is consistent with an intentionally projected remaining-depth budget. No nested Agent call, repository mutation, permission bypass, fork, or background execution was involved.