claude-code - 💡(How to fix) Fix Built-in worker and quick subagent types never receive tool definitions (0% tool access across 150 invocations) [3 comments, 2 participants]

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

1. Start a Claude Code session
2. Ask Claude to perform a task that triggers subagent_type: "worker" or "quick" (e.g., a code review that gets delegated to worker agents)
3. Observe that the subagent's result metadata shows tool_uses: 0
4. 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:

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 (never type: "tool_use")
• input_tokens: 3 on continuation messages (suggesting minimal/broken context)
• Tool call XML rendered as plain text in the output
• stop_reason alternating 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, websearch
• quick: 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