Grep and Glob tools missing entirely from registry under ENABLE_TOOL_SEARCH=true

Open 💬 15 comments Opened Apr 22, 2026 by saminstacart

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 (build 25E253)
  • Model: Opus 4.7 (claude-opus-4-7)
  • Provider: Vertex via a non-first-party AI gateway proxy
  • ENABLE_TOOL_SEARCH=true set in ~/.claude/settings.json env block
  • Permissions explicitly allow Grep and Glob (both in user settings and marketplace-managed permissions)

Repro

  1. Set ENABLE_TOOL_SEARCH=true in ~/.claude/settings.json env field.
  2. Start a fresh Claude Code session against an Anthropic-compatible proxy.
  3. Inspect the available tools (top-level) — Grep and Glob are absent.
  4. Call ToolSearch with query: "select:Grep,Glob" — returns no results.
  5. Call ToolSearch with broad keywords like grep, 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.

View original on GitHub ↗

15 Comments

tpeacock19 · 2 months ago

I am also experiencing a similar issue. The agent does not have access to a number of core built-in tools without using ToolSearch first.

Summary

The ENABLE_TOOL_SEARCH feature (default true) — 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 extra ToolSearch round-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_SEARCH should 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> until ToolSearch is invoked to fetch their schemas:

  • EnterPlanMode, ExitPlanMode
  • AskUserQuestion
  • TaskCreate, TaskGet, TaskList, TaskOutput, TaskStop, TaskUpdate
  • WebFetch, WebSearch
  • LSP
  • NotebookEdit
  • Monitor
  • CronCreate, CronDelete, CronList
  • PushNotification, RemoteTrigger
  • EnterWorktree, ExitWorktree

Concrete 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 EnterPlanMode on the first attempt because its schema was not in context — it had to call ToolSearch with select:EnterPlanMode first to fetch it. This is an unnecessary round-trip for a core harness feature that has no substitute, and it is easy to miss: ExitPlanMode alone doesn't enter plan mode, so a model that fetches only ExitPlanMode ends up with a confusing "not in plan mode" error and has to fetch again.

Environment

  • Claude Code CLI (2.1.118) on macOS (Darwin 23.5.0)
  • Model: Opus 4.7 (1M context)
  • ENABLE_TOOL_SEARCH: unset (default true)

Workaround

Set ENABLE_TOOL_SEARCH=false (as an env var, or in ~/.claude/settings.json under env) to force eager loading of all tool schemas. This works but defeats the token-saving benefit for users with many MCP servers installed.

nerrante · 2 months ago

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.

ah4c · 2 months ago

Still reproduces in 2.1.126 (latest as of 2026-05-01) with default settings (ENABLE_TOOL_SEARCH unset). 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.

travisfrels-upstart · 2 months ago

Reproduces on 2.1.126, macOS arm64 native, default settings. Glob and Grep absent from the base palette and from ToolSearch's deferred registry. Same in general-purpose / Explore subagents — not asymmetric.

ENABLE_TOOL_SEARCH=false does not resolve it here. Tested with =false set in ~/.claude/settings.json, restarted; verified on 2.1.126 (latest) and 2.1.118 (stable). Glob and Grep remain absent. ToolSearch itself does disappear from the palette — eager-loading is active — but the registration gap is unchanged.

2.1.116–2.1.126 all affected.

ah4c · 2 months ago

Still reproduces in 2.1.128. No change in behaviour — Glob and Grep absent from both base palette and deferred registry. New tool ShareOnboardingGuide appeared in the base palette but does not affect the issue.

ah4c · 2 months ago

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.

 ▐▛███▜▌   Claude Code v2.1.138
▝▜█████▛▘  Opus 4.7 (1M context) · Claude Team
  ▘▘ ▝▝    /private/tmp

❯ are Glob and Grep tools available?

⏺ No. My available tools this session are: Agent, AskUserQuestion, Bash, Edit, Read, ScheduleWakeup, Skill, ToolSearch, Write. Glob and Grep are not present, and they're not in the deferred-tools list either (so ToolSearch can't load them).
ah4c · 2 months ago

Still reproduces in 2.1.142 (tested in /private/tmp, no project context, no MCP servers).

ah4c · 1 month ago

Still reproduces in 2.1.146 (tested in /private/tmp, no project context, no MCP servers).

hhevlow · 1 month ago

Still reproduces in 2.1.149 (CLI, macOS arm64, Darwin 24.6.0, Opus 4.7 1M). Glob and Grep absent from both the base palette and the ToolSearch deferred registry — ToolSearch select:Grep,Glob returns "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.json denies the Bash grep/find/cat commands to steer work toward the Grep/Glob tools. With those tools missing from the registry, there's no first-class search path left — only Read on known paths or sub-agents. So the registration gap is materially worse for repos that (reasonably) block the Bash equivalents.

ftrinityd · 1 month ago

Still reproducible in 2.1.154 (CLI, macOS arm64)

stephenmcm · 1 month ago

Glob isn't available directly — let me use Bash.
Claude Code v2.1.161 (CLI, macOS arm64)

hendie · 1 month ago

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:

  1. Not proxy-specific. This session is on the first-party Anthropic API — no ANTHROPIC_BASE_URL set (only an unrelated custom *_LOCAL var). The original report wondered whether the registration bug was tied to the Vertex/proxy path; it isn't.
  2. Genuinely unregistered, not just deferred. Invoking Grep returns Error: No such tool available: Grep — distinct from the InputValidationError a deferred-but-unloaded tool raises. So Grep/Glob aren't in the deferred registry at all; they're dropped entirely.

Confirmed clean of confounders: no permissions.deny, no disabledTools, no managed/enterprise settings, no tool-disabling env var. ripgrep 15.1.0 is installed and working (matching #63525's note that the agent mis-diagnoses this as "rg not installed"). The collision with hooks that redirect bash grep/findGrep/Glob leaves no filesystem-search path without a manual workaround.

felix-eschey · 1 month ago

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 Code: 2.1.177
  • Model: Opus 4.8 (claude-opus-4-8)
  • Platform: Linux 6.17 (x86_64)
  • Provider: first-party Anthropic API (no ANTHROPIC_BASE_URL)
  • ENABLE_TOOL_SEARCH: unset (default)

Grep and Glob are absent from the active palette and from the ToolSearch deferred registry: ToolSearch select:Grep,Glob returns "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, no disabledTools/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.

sankalpsharmaa · 1 month ago

Still reproduces on 2.1.178 (CLI, macOS arm64, Darwin 25.5.0, Opus 4.8 claude-opus-4-8, first-party Anthropic API — no ANTHROPIC_BASE_URL). Extends the confirmed range past @felix-eschey's 2.1.177; now 2.1.116 → 2.1.178.

Grep and Glob are absent from the active palette and the ToolSearch deferred registry. Invoking Grep returns:

Error: No such tool available: Grep. Grep is not available in this session — search file contents with `grep` via the Bash tool instead.

That's the No such tool available form, not InputValidationError — genuinely unregistered, not deferred-but-unloaded (matches @hendie's 2.1.173 and @felix-eschey's 2.1.177 notes). For contrast, the Task* family and WebFetch/WebSearch are in the deferred list and load fine via ToolSearch; only Grep/Glob are dropped entirely.

Confounders ruled out for this report:

  • Not plugin-related — we first suspected a plugin was forcing a degraded tool surface; disabling the suspect plugin and restarting changed nothing.
  • No ANTHROPIC_BASE_URL (first-party API), so not the proxy path — corroborates @hendie.
  • No permissions.deny, no disabledTools/disallowedTools, no managed/enterprise settings.
  • ENABLE_TOOL_SEARCH unset (default) during the broken session.

On the ENABLE_TOOL_SEARCH=false workaround: flagging that it may not be reliable — @travisfrels-upstart reported =false did not restore Grep/Glob on 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 is Bash, which directly collides with the common hook setup that blocks bash grep/find to steer toward Grep/Glob.

Third-Thing · 11 days ago
Native builds on macOS and Linux: the Glob and Grep tools are replaced by embedded bfs and ugrep available through the Bash tool — faster searches without a separate tool round-trip (Windows and npm-installed builds unchanged)

https://code.claude.com/docs/en/changelog#2-1-117

Sorry but the CHANGELOG was misleading. These [bfs and ugrep] are aliased to find and grep in Claude's shell but they are not intended to be accessed directly.

https://github.com/anthropics/claude-code/issues/52476

...the removal in v2.1.117 was by design (embedded bfs/ugrep via Bash, per the changelog), but the model's own guidance and the user-facing docs were never updated to match — so the model still advertises and reaches for Glob/Grep, and users keep re-discovering the absence the hard way (hence those three separate reports over several months). Fixing the messaging — model guidance + docs (https://github.com/anthropics/claude-code/issues/51781) — is what prevents further duplicates.

https://github.com/anthropics/claude-code/issues/69849