[BUG] Subagent with `hooks: []` (empty array) in frontmatter is silently dropped from the agent list (`--agent '<name>' not found`, no warning)
Summary
A subagent definition (~/.claude/agents/<name>.md or .claude/agents/<name>.md) whose frontmatter contains hooks: [] (an empty YAML array) is silently excluded from the loaded agent list. There is no warning on stderr, nothing in --debug output, and the file is otherwise valid. The only observable symptom is that claude --agent <name> reports --agent '<name>' not found and the agent cannot be spawned via the Agent tool either.
hooks: {} (empty mapping) and omitting the hooks key entirely both load normally. Only the empty-array form triggers the silent drop.
Environment
- Claude Code: reproduced on 2.1.251, 2.1.258 and 2.1.259 (current at time of filing; still unfixed)
- OS: macOS (Darwin 25.x), zsh
- Scope: user-level (
~/.claude/agents/) and project-level (.claude/agents/) both affected - Not a plugin agent (plugin agents ignore
hooksby design per the docs)
Steps to reproduce
Create three minimal agent files in an isolated project directory (.claude/agents/):
probe-empty-array.md (fails to load)
---
name: probe-empty-array
description: probe
hooks: []
---
You are a probe.
probe-empty-map.md (loads)
---
name: probe-empty-map
description: probe
hooks: {}
---
You are a probe.
probe-no-key.md (loads)
---
name: probe-no-key
description: probe
---
You are a probe.
Then run the following probe for each (no API call is made; it fails fast on the empty prompt, which is enough to tell whether the agent resolved):
claude --agent probe-empty-array -p "" </dev/null 2>&1 | head -1
claude --agent probe-empty-map -p "" </dev/null 2>&1 | head -1
claude --agent probe-no-key -p "" </dev/null 2>&1 | head -1
Actual result
--agent 'probe-empty-array' not found. Available agents: probe-empty-map, probe-no-key, ...
Error: Input must be provided either through stdin or as a prompt argument
Error: Input must be provided either through stdin or as a prompt argument
probe-empty-arrayis missing fromAvailable agents:and cannot be used.- No warning or error mentions the file, the
hooksfield, or a schema/validation failure.--debugis equally silent about it. - The same file with the single
hooks: []line removed loads immediately (A/B verified on 2.1.251 and 2.1.259).
Expected result
One of:
hooks: []is treated as "no hooks" (same ashooks: {}/ key absent), or- the agent is still skipped, but Claude Code emits a clear warning such as
agents/probe-empty-array.md: invalid frontmatter field "hooks" (expected mapping of event -> matchers, got array); agent not loaded.
Silently dropping a whole agent definition over an optional field is the worst of both worlds: the file exists, ls shows it, and nothing explains why the agent is gone.
Suspected cause
The frontmatter hooks field is validated against an object schema ({ EventName: [ { matcher, hooks: [...] } ] }). An empty YAML array is not an object, so validation fails, and the failure path appears to discard the entire agent definition (unloadable guard) rather than ignoring the field or surfacing the error.
Why this matters
- Agent definitions that were written before the stricter validation (with
hooks: []as a "no hooks" placeholder) stop loading after upgrading, with no signal. In our case a routine agent was unavailable for several days before anyone noticed it was missing from the agent list. - File-existence checks cannot detect it; only a runtime probe like the one above does.
- If other optional frontmatter fields (
mcpServers,skills, ...) share the same validate-then-discard path, the same silent failure mode would apply to type mismatches there too.
Relation to existing issues
- #80890 (agent silently skipped due to CRLF line endings / unquoted
:indescription) and #76499 (CRLF) describe the same symptom class (agent silently absent from the list) but a different trigger (frontmatter parse failure). This report is a valid, LF-only, correctly quoted frontmatter that parses fine; the drop is caused specifically by thehooksvalue type failing schema validation after parsing. - #73865 (identical sibling agents load fine) is likewise a different root cause.
Suggested fix
- Accept an empty array for
hooks(coerce[]to{}/ undefined), and - On any frontmatter schema validation failure, log a warning naming the file and the offending field instead of silently unloading the agent (or load the agent with the invalid optional field ignored).