Built-in worker and quick subagent types never receive tool definitions (0% tool access across 150 invocations)
Summary
The built-in worker and quick subagent types never receive tool definitions at runtime, despite being documented as having tool access (bash, read, write, edit, glob, grep etc.). This results in tool_uses: 0 on every invocation. The model generates tool call XML as plain text, which is never parsed or executed by the harness. In code review and analysis tasks, this leads to agents fabricating detailed findings (line numbers, code snippets, severity ratings) for files they never read.
Environment
- Claude Code version: 2.1.138
- OS: macOS (Darwin 25.2.0)
- Shell: zsh
Reproduction
- Start a Claude Code session
- Ask Claude to perform a task that triggers
subagent_type: "worker"or"quick"(e.g., a code review that gets delegated to worker agents) - Observe that the subagent's result metadata shows
tool_uses: 0 - The subagent's text output contains raw
<function_calls>/<invoke>XML that was never executed
Evidence
Analyzed session JSONL files across 3 days of usage. Subagent tool access by type:
| Agent Type | Model | Tool Access | Invocations | Success Rate |
|---|---|---|---|---|
| general-purpose | claude-opus-4-6 | YES | 152 | 99% |
| Explore | claude-haiku-4-5 | YES | 112 | 100% |
| Plan | claude-opus-4-6 | YES | 9 | 100% |
| worker | claude-sonnet-4-6 | NO | 62 | 0% |
| quick | claude-haiku-4-5 | NO | 88 | 0% |
This is 100% reproducible — not a single worker or quick subagent has ever executed a tool call across 150 combined invocations.
Specific failure session
Session 931055fa: Parent spawned 4 parallel agents with subagent_type: "worker" for code review. All 4 had tool_uses: 0. The subagent JSONL files show:
- Assistant messages contain only
type: "text"content blocks (nevertype: "tool_use") input_tokens: 3on continuation messages (suggesting minimal/broken context)- Tool call XML rendered as plain text in the output
stop_reasonalternating between"max_tokens",null, and"end_turn"
Hallucination cascade
When tools don't execute, 3 out of 4 agents fabricated detailed "bug reports" with:
- Specific line numbers (wrong)
- Code snippets (invented from training data, not from the actual files)
- Severity ratings and fix recommendations
Only 1 agent honestly reported: "The tool calls don't seem to be going through... The tools appear completely unresponsive."
The parent then had to manually read every file and verify every claim — all were false positives. This wasted ~15 minutes of wall time and significant token usage.
Expected behavior
worker and quick subagent types should receive the tool definitions documented in their agent type descriptions:
worker: bash, read, write, edit, glob, grep, webfetch, websearchquick: bash, read, glob, grep, webfetch, websearch
Alternatively, if these types are intentionally toolless, the parent model's agent type selection logic should prevent choosing them for tasks that require file I/O.
Related issues
- #56398 — Named subagents don't get tool access (same symptom, different scope: custom agents)
- #57038 — Subagent fabricates tool outputs with sonnet model (likely same root cause)
- #4462 — Sub-agents claim file creation but files don't persist
- #6836 — Meta issue tracking tool_use/tool_result mismatches
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗