[BUG] Subagents can't reach deferred built-in tools (WebFetch, Monitor, DesignSync, …). No ToolSearch to load them, regardless of tools: frontmatter

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Subagents never receive a working ToolSearch tool. Since v2.1.69, built-in tools beyond the small always-loaded set (Read, Grep, Glob, Bash, Edit, Write, etc.) are deferred and only become callable after ToolSearch loads them into context (see #31002). Because subagents don't get ToolSearch, any deferred built-in tool. WebFetch, Monitor, and integration tools like DesignSync. is permanently unreachable from a subagent, no matter how it's declared in the agent's tools: frontmatter.

The tool is silently absent from the subagent's inventory: no error, no warning, nothing in the debug log pointing at the real cause.

This is distinct from #25200 and #34935 (both closed as not planned), which are about MCP servers specifically. This report is about built-in deferred tools with no MCP server involved at all. confirmed by elimination.

There's also #41408 (also closed as not planned), which reports the same symptom for general-purpose subagents specifically with WebSearch/WebFetch, and attributes it to tools: * not expanding to include deferred tools. Contrasting with Explore/claude-code-guide, which do get those tools because their tool list is defined explicitly rather than via wildcard.

This report's reproduction rules that explanation out as the root cause: the subagent here is a custom agent with tools: naming the deferred tool explicitly by name (no wildcard at all), and it still never becomes reachable. The common thread across all three closed reports is simpler and more general than any one of them states individually: subagents don't have ToolSearch, so no deferred tool reaches them, regardless of whether the tool list is *, an explicit name, or an MCP reference. Explore and claude-code-guide are the exception only because their deferred tools are documented as pre-loaded into those specific built-in types, not discovered via ToolSearch at runtime . They aren't evidence that explicit naming solves the problem for a custom subagent.

No .mcp.json exists in the project.
grep -rn "DesignSync" .claude/ ~/.claude/settings.json returns nothing outside the agent file itself.
Sibling subagents in the same project that declare real MCP tools (e.g. mcp__some-server__some-tool) work correctly. Ruling out MCP name-resolution bugs as the cause.

Asking the affected subagent to report its own tool list confirms ToolSearch itself is absent. Which is the actual root cause: without ToolSearch, nothing deferred can ever load, regardless of what tools: declares.

What Should Happen?

One of:

A subagent that explicitly declares a deferred built-in tool in tools: should be able to load and call it. Either via a working ToolSearch scoped to what its frontmatter resolves to, or by hard-injecting that tool into its initial inventory.
If neither is possible, Claude Code should fail loudly at spawn time, naming the tool it can't make reachable. The same way it already errors when a tools: entry resolves to nothing at all (the "Agent would be spawned with zero tools" path).

Either behavior is better than the current one: silent, undetectable absence.

Error Messages/Logs

None. This is the core problem. The failure produces no error, no warning, and no debug-log entry naming a missing capability. claude --debug shows a normal spawn and normal tool resolution; the gap only becomes visible by asking the subagent to dump its own tool list and noticing ToolSearch isn't in it.

Steps to Reproduce

1. Define a project subagent in .claude/agents/my-agent.md:

   ---
   name: my-agent
   description: Test agent for deferred tool access
   tools: Read, Glob, Grep, Bash, DesignSync
   ---
   Your only job is to report your exact tool list, verbatim, and nothing else.

(Any deferred built-in reproduces this — WebFetch works too and doesn't require a DesignSync-enabled account.)

2. Confirm the tool is not MCP-backed:
No .mcp.json in the project.
grep -rn "DesignSync" .claude/ ~/.claude/settings.json returns nothing outside the agent file itself.
Any sibling agent in the project that declares a real MCP tool (mcp__<server>__<tool>) works fine as a subagent, ruling out MCP name-resolution as the cause.

3. Spawn my-agent via the Agent tool and ask it to report its tool list.

Expected: the declared tool is available, or Claude Code fails at spawn time naming the unresolvable tool.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.221

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Cursor

Additional Information

Related issues (both closed as not planned, both assume an MCP server is involved — this report doesn't have one):

[](https://github.com/anthropics/claude-code/issues/25200) Same symptom shape (declared tool never reaches subagent, no error), but scoped to mcpServers: frontmatter specifically.
[](https://github.com/anthropics/claude-code/issues/34935) General MCP-passthrough feature request, also MCP-scoped.
[](https://github.com/anthropics/claude-code/issues/31002) Documents that built-in tools became deferred behind ToolSearch starting v2.1.69, which is the mechanism this bug depends on.
[](https://github.com/anthropics/claude-code/issues/41408) same symptom for general-purpose subagents with WebSearch/WebFetch, attributed to tools: * not expanding to deferred tools. This report's reproduction (explicit tool name, no wildcard, still unreachable) shows that explanation doesn't hold, the actual gap is the missing ToolSearch, independent of how the tool list is written.

Suggested fixes, any of which would help:

Grant subagents a working ToolSearch, scoped to whatever their own tools:/mcpServers: frontmatter resolves to.
Hard-inject explicitly declared deferred tools into the subagent's initial inventory instead of relying on ToolSearch discovery.
Fail loudly at spawn time when a tools: entry resolves to a deferred tool the subagent has no way to load.
Document this limitation in the subagent tools reference. The current docs' "inherits every tool available to subagents" language reads as covering this case, and it doesn't.

Reproduced with a project-level subagent in .claude/agents/, not a plugin-provided one.