Grep and Glob tools missing entirely from registry under ENABLE_TOOL_SEARCH=true
Summary
When ENABLE_TOOL_SEARCH=true is set, the built-in Grep and Glob tools disappear from the session entirely — they are neither preloaded as direct tools nor present in the deferred-tool list returned by ToolSearch. The documentation states tool search defers MCP tools, so built-ins like Grep/Glob should not be affected.
Environment
- Claude Code:
2.1.117 - Node:
v24.10.0 - macOS:
26.4.1(build25E253) - Model: Opus 4.7 (
claude-opus-4-7) - Provider: Vertex via a non-first-party AI gateway proxy
ENABLE_TOOL_SEARCH=trueset in~/.claude/settings.jsonenv block- Permissions explicitly allow
GrepandGlob(both in user settings and marketplace-managed permissions)
Repro
- Set
ENABLE_TOOL_SEARCH=truein~/.claude/settings.jsonenv field. - Start a fresh Claude Code session against an Anthropic-compatible proxy.
- Inspect the available tools (top-level) —
GrepandGlobare absent. - Call
ToolSearchwithquery: "select:Grep,Glob"— returns no results. - Call
ToolSearchwith broad keywords likegrep,glob,search files— they are not in the deferred-tool list at all.
Expected
Per the docs, tool search defers MCP tools on demand. Built-in tools (Grep, Glob, Read, Edit, Write, Bash, etc.) should remain available — either preloaded or at minimum discoverable via ToolSearch.
Actual
Read, Edit, Write, Bash, Agent, Skill, ToolSearch are preloaded. AskUserQuestion, WebFetch, WebSearch, NotebookEdit, etc. show up in the deferred list. Grep and Glob are in neither list. They cannot be invoked at all.
This also affects subagents (e.g. Explore) launched from the parent — they inherit the same gap.
Impact
This collides with ~/.claude/hooks/ setups that block bash grep/find and redirect users to Grep/Glob. Result: no path to filesystem search at all without a manual workaround.
Workaround
Patched the redirect hook to honor a CLAUDE_DEGRADED_NATIVE_TOOLS=Grep,Glob env var that allows bash grep/find to fall through when the named native tools are unavailable. Works, but masks a real registration bug.
Note on proxy default
Docs state that when ANTHROPIC_BASE_URL points to a non-first-party host, tool search defaults to OFF because most proxies do not forward tool_reference blocks. Setting =true explicitly was intentional. Possible the registration bug is specific to the proxy path — happy to provide more diagnostic info if useful.
15 Comments
I am also experiencing a similar issue. The agent does not have access to a number of core built-in tools without using
ToolSearchfirst.Summary
The
ENABLE_TOOL_SEARCHfeature (defaulttrue) — documented under MCP configuration — defers schema loading for first-party Claude Code tools, not just tools provided by MCP servers. This forces the model to make an extraToolSearchround-trip before it can invoke core harness functionality like plan mode, task tracking, or web fetch.Expected behavior
Based on naming and documentation location (under "MCP"),
ENABLE_TOOL_SEARCHshould apply only to MCP server tools, where user-installed integrations can balloon the tool-schema footprint. First-party tools that are part of the Claude Code surface (plan mode, tasks, web fetch, LSP, etc.) should always be eagerly loaded so the model can use them without a fetch round-trip.Actual behavior
The following first-party tools are deferred by default and appear only by name in a
<system-reminder>untilToolSearchis invoked to fetch their schemas:EnterPlanMode,ExitPlanModeAskUserQuestionTaskCreate,TaskGet,TaskList,TaskOutput,TaskStop,TaskUpdateWebFetch,WebSearchLSPNotebookEditMonitorCronCreate,CronDelete,CronListPushNotification,RemoteTriggerEnterWorktree,ExitWorktreeConcrete symptom
In an Opus 4.7 session, the user asked the model to "enter plan mode and create a plan." The model could not call
EnterPlanModeon the first attempt because its schema was not in context — it had to callToolSearchwithselect:EnterPlanModefirst to fetch it. This is an unnecessary round-trip for a core harness feature that has no substitute, and it is easy to miss:ExitPlanModealone doesn't enter plan mode, so a model that fetches onlyExitPlanModeends up with a confusing "not in plan mode" error and has to fetch again.Environment
ENABLE_TOOL_SEARCH: unset (defaulttrue)Workaround
Set
ENABLE_TOOL_SEARCH=false(as an env var, or in~/.claude/settings.jsonunderenv) to force eager loading of all tool schemas. This works but defeats the token-saving benefit for users with many MCP servers installed.Also affected on macOS desktop app, 2.1.116 CLI works fine after downgrading but app does not. Symptom matches #52004 eight-tool fingerprint exactly.
Still reproduces in 2.1.126 (latest as of 2026-05-01) with default settings (
ENABLE_TOOL_SEARCHunset). Tested on macOS, native install, both Sonnet 4.6 and Opus 4.7 — model makes no difference, tool palette is fixed at session start by the harness. Glob and Grep absent from both base palette and deferred registry.Reproduces on 2.1.126, macOS arm64 native, default settings.
GlobandGrepabsent from the base palette and fromToolSearch's deferred registry. Same ingeneral-purpose/Exploresubagents — not asymmetric.ENABLE_TOOL_SEARCH=falsedoes not resolve it here. Tested with=falseset in~/.claude/settings.json, restarted; verified on 2.1.126 (latest) and 2.1.118 (stable). Glob and Grep remain absent.ToolSearchitself does disappear from the palette — eager-loading is active — but the registration gap is unchanged.2.1.116–2.1.126 all affected.
Still reproduces in 2.1.128. No change in behaviour — Glob and Grep absent from both base palette and deferred registry. New tool
ShareOnboardingGuideappeared in the base palette but does not affect the issue.Still reproduces in 2.1.138 (tested in /private/tmp, no project context, no MCP servers). Now broken across 2.1.117–2.1.138.
Still reproduces in 2.1.142 (tested in /private/tmp, no project context, no MCP servers).
Still reproduces in 2.1.146 (tested in /private/tmp, no project context, no MCP servers).
Still reproduces in 2.1.149 (CLI, macOS arm64, Darwin 24.6.0, Opus 4.7 1M).
GlobandGrepabsent from both the base palette and theToolSearchdeferred registry —ToolSearch select:Grep,Globreturns "No matching deferred tools," and keyword searches never surface them.Extra data point: hit this inside a git worktree session (
claude -w work1) on a repo whose.claude/settings.jsondenies the Bashgrep/find/catcommands to steer work toward theGrep/Globtools. With those tools missing from the registry, there's no first-class search path left — onlyReadon known paths or sub-agents. So the registration gap is materially worse for repos that (reasonably) block the Bash equivalents.Still reproducible in
2.1.154(CLI, macOS arm64)Glob isn't available directly — let me use Bash.Claude Code v2.1.161 (CLI, macOS arm64)
Still reproduces on the latest build — Claude Code 2.1.173, Opus 4.8 (
claude-opus-4-8), macOS (darwin 25.4.0). The newest env data point here was 2.1.156 (#63525, closed as dup of this), so confirming it's not yet fixed.Two data points that may help narrow it:
ANTHROPIC_BASE_URLset (only an unrelated custom*_LOCALvar). The original report wondered whether the registration bug was tied to the Vertex/proxy path; it isn't.GrepreturnsError: No such tool available: Grep— distinct from theInputValidationErrora deferred-but-unloaded tool raises. SoGrep/Globaren't in the deferred registry at all; they're dropped entirely.Confirmed clean of confounders: no
permissions.deny, nodisabledTools, no managed/enterprise settings, no tool-disabling env var.ripgrep 15.1.0is installed and working (matching #63525's note that the agent mis-diagnoses this as "rg not installed"). The collision with hooks that redirect bashgrep/find→Grep/Globleaves no filesystem-search path without a manual workaround.Still reproduces on 2.1.177 (CLI), and this is a Linux data point, which I don't see elsewhere in the thread (reports so far are macOS arm64).
claude-opus-4-8)ANTHROPIC_BASE_URL)ENABLE_TOOL_SEARCH: unset (default)GrepandGlobare absent from the active palette and from the ToolSearch deferred registry:ToolSearch select:Grep,Globreturns "No matching deferred tools found," and keyword searches never surface them. So they're dropped entirely, not just deferred (matches @hendie's 2.1.173 note).Confirmed clean of confounders: checked user, project, and local settings — no
permissions.deny, nodisabledTools/disallowedTools, no managed/enterprise settings, no tool-disabling env var.So this now spans 2.1.116 → 2.1.177, on Linux as well as macOS, and is not proxy-specific.
Still reproduces on 2.1.178 (CLI, macOS arm64, Darwin 25.5.0, Opus 4.8
claude-opus-4-8, first-party Anthropic API — noANTHROPIC_BASE_URL). Extends the confirmed range past @felix-eschey's 2.1.177; now 2.1.116 → 2.1.178.GrepandGlobare absent from the active palette and the ToolSearch deferred registry. InvokingGrepreturns:That's the
No such tool availableform, notInputValidationError— genuinely unregistered, not deferred-but-unloaded (matches @hendie's 2.1.173 and @felix-eschey's 2.1.177 notes). For contrast, theTask*family andWebFetch/WebSearchare in the deferred list and load fine via ToolSearch; onlyGrep/Globare dropped entirely.Confounders ruled out for this report:
ANTHROPIC_BASE_URL(first-party API), so not the proxy path — corroborates @hendie.permissions.deny, nodisabledTools/disallowedTools, no managed/enterprise settings.ENABLE_TOOL_SEARCHunset (default) during the broken session.On the
ENABLE_TOOL_SEARCH=falseworkaround: flagging that it may not be reliable — @travisfrels-upstart reported=falsedid not restoreGrep/Globon 2.1.126 (ToolSearch disappears, eager-loading engages, but the registration gap remains). If that holds on current builds, there is no configuration that restores first-class filesystem search — the only path left isBash, which directly collides with the common hook setup that blocks bashgrep/findto steer towardGrep/Glob.https://code.claude.com/docs/en/changelog#2-1-117
https://github.com/anthropics/claude-code/issues/52476
https://github.com/anthropics/claude-code/issues/69849