[BUG] Subagents aren't shown the agent-type roster their Agent tool docs promise (injected lazily; visibility only, not availability)

Preflight

• [x] I have searched existing issues and this specific angle isn't reported
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.179)

Summary

A subagent launched via the Agent tool does not receive the roster of available agent types (subagent_type values) in its initial context. The subagent's own Agent tool description tells it where to find that roster — verbatim: "Available agent types are listed in <system-reminder> messages in the conversation" — but no such reminder is present at subagent startup. The roster is injected lazily: it appears only after a later triggering event (e.g. a Skill tool invocation, or the subagent's first Agent tool call).

This is a visibility problem, not an availability one — named types still resolve and launch fine before the roster appears (see "Scope" below). The effect is that a subagent cannot discover which specialized types exist: it reads its own tool docs promising a list, finds none, and is left with only the documented general-purpose default. The top-level (interactor) session, by contrast, receives the roster in its initial context.

Reproduction (visibility)

1. From a top-level session, launch a subagent (e.g. general-purpose) and ask it to scan its full context for a roster of agent types / valid subagent_type values.

• Result: no roster present. The subagent has CLAUDE.md/AGENTS.md, the deferred-tools list, and the skills listing — but no agent-type roster.

1. In a fresh subagent: (a) confirm no roster is present, (b) load any skill via the Skill tool (e.g. coherence), (c) re-scan context.

• Result: after the Skill load, a fresh <system-reminder> containing the full agent-type roster appears.

I ran step 1 three times (three independent subagents); all three reported no roster. Step 2 reproduced the lazy appearance.

Scope: visibility only, not availability

I tested whether named types actually resolve for a subagent while the roster is still invisible to it. In a fresh subagent, before loading any skill, the first action was an Agent call:

• subagent_type: "Explore" with a trivial prompt → launched and returned successfully, even though no roster was visible at invocation time.
• Control subagent_type: "definitely-not-a-real-agent-xyz" → failed with:

``
Agent type 'definitely-not-a-real-agent-xyz' not found. Available agents: claude, claude-code-guide, code-reviewer, debugger, design-investigator, document-refiner, Explore, general-purpose, general-purpose-interlocutor, planner, prompt-engineer, researcher, technical-investigator
``

So invocation is validated against the true backend roster regardless of what's rendered in the subagent's context. Visibility (what the subagent can see to choose from) and availability (what resolves on invocation) are decoupled. A subagent can launch a correctly-named specialized type "blind," but has no in-context way to learn the names.

Notably, the not-found error itself enumerates the full roster — and the first Agent call also triggers the lazy injection, so a Skill load is not the only trigger.

Detail

• At subagent start: skills listing present, agent-type roster absent. The two are coupled in the top-level session's initial system-reminder but decoupled at subagent init.
• The Agent tool description in the subagent's context states verbatim: "Available agent types are listed in <system-reminder> messages in the conversation." The only type named anywhere otherwise is general-purpose (documented default).
• Known triggers that inject the roster after the fact: a Skill tool invocation, and the subagent's first Agent tool call.

Why this matters

A subagent has the Agent tool (often with */all tools) and may legitimately delegate to scoped helpers. But it's pointed at a list of agent types that isn't there, so it can't make an informed choice — it either guesses a name (and only a specialized-type guess that happens to be exactly right will work) or falls back to general-purpose, even when a specialized type would be correct. Same class as #35240 (tool docs reference a capability — SendMessage — not present in context).

Expected

Either:

1. Inject the agent-type roster into the subagent's initial context (matching the top-level session and the Agent tool's own documentation), or
2. If subagents are intentionally not given the roster up front, adjust the subagent-facing Agent tool description so it doesn't promise a list that isn't delivered at that point.

Related issues

• #35240 — Agent tool docs reference SendMessage (flag-gated) the model can't access. Same class: docs promise a capability not present in context.
• #34039 — SessionStart hook output and skills listing re-injected on every --resume. Same area: system-reminder / listing injection timing.

Is this a regression?

I don't know — I haven't tested earlier versions.

Environment

• Claude Code: 2.1.179
• Model: claude-opus-4-8[1m]
• Platform: Anthropic API (Claude Code CLI)
• OS: macOS 26.4.1 (Darwin 25.4.0)