Custom subagent registry silently caps at 3 (not documented), drops alphabetically-last entries with no load-time error

Summary

The custom subagent registry (files in .claude/agents/*.md, user- or project-level) silently
caps the number of loadable custom agents. With 5 agent files defined, only 3 loaded — the
alphabetically-last 2 were dropped with no error at session start, only a 404 at invoke time.

Repro

1. Define 5 custom agent .md files in ~/.claude/agents/: analyst, engineer, researcher,

risk-reviewer, specialist (all valid frontmatter, valid model: IDs).

1. Start a session. No warning/error is printed about any agent being dropped.
2. Call Agent({subagent_type: "specialist", ...}).

Expected

Either all 5 agents load, or a clear warning at session start names which ones were dropped
and why (e.g. "registry capped at N, dropping: risk-reviewer, specialist").

Actual

Only analyst, engineer, researcher are available. specialist and risk-reviewer 404 at
invoke time: Agent type 'specialist' not found. Available agents: analyst, claude,
claude-code-guide, engineer, Explore, general-purpose, Plan, researcher, statusline-setup.
The dropped entries are consistently the alphabetically-last ones among the custom set.

Additional test

Tried splitting the 5 files across scopes — 3 in ~/.claude/agents/ (user-level), 2
(risk-reviewer.md, specialist.md) copied into project-level .claude/agents/ — to see if
scoping worked around the cap. It did not: still only 3 total loaded, same 2 still missing.
This suggests the effective pool is combined across user+project scope and the cap applies to
the union, not per-scope.

Impact

Silent failure mode: routing logic (e.g. a CLAUDE.md table like "before any git push, run
risk-reviewer") can reference an agent that no longer resolves, with no signal until the
exact call site 404s. For safety-gate workflows this is a real risk — a hard gate can silently
stop being enforced.

Environment

• Claude Code (Windows 11, win32)
• Reproduced 2026-08-22