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

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.

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_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.

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.

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.

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).

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). 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.

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:

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/find → Grep/Glob leaves 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 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.

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.

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

Seeing this on 2.1.214, and with a couple of details that widen the repro beyond the title:

• ENABLE_TOOL_SEARCH unset (i.e. Tool Search on by default) — not forced =true.
• ANTHROPIC_BASE_URL unset → first-party API, no gateway/proxy.
• No disallowedTools / allowedTools in settings.json.

So it's not limited to explicitly forcing Tool Search on, and it's not proxy-specific — it happens on stock first-party config too.

It's also intermittent. On affected sessions, Grep and Glob are absent from the active tool set and from the deferred registry — ToolSearch({query: "select:Grep,Glob"}) returns "No matching deferred tools found" — while every other built-in (Read/Edit/Write/Bash/Agent/Skill/ToolSearch) is present. But simply restarting brought them back in a later session with no config change. That points at a registration race at session start rather than a deterministic config-driven drop.

Note this recurs well past the 2.1.117 origin, so whatever landed since hasn't fully closed it. (#63525 was closed as a duplicate of this one.)

Adding measured data that separates the client's behavior from the endpoint's, since this thread has both a proxy/Vertex repro and a first-party one.

I logged the outgoing /v1/messages request (a logging sink in front of the endpoint) for two accounts on 2.1.217, both with ENABLE_TOOL_SEARCH=true and one MCP server. The tools array is byte-identical between an OAuth session on api.anthropic.com and a real third-party session (z.ai, GLM):

• LOADED, full schema: Agent, Bash, Edit, Read, ReportFindings, ScheduleWakeup, Skill, ToolSearch, Workflow, Write
• DEFERRED: a single DeferredToolPlaceholder
• anthropic-beta includes advanced-tool-use-2025-11-20

So the client marks the same core set loaded and collapses everything else (MCP tools plus Grep/Glob/NotebookEdit/…) into the placeholder, regardless of endpoint. Grep/Glob land in the deferred bucket, which lines up with this issue.

The divergence is in what the model actually receives. Functional test, asking each model to call Bash and echo a token:

| endpoint | Bash directly available | turns |
|---|---|---|
| api.anthropic.com (Opus) | yes | 2 |
| third-party Anthropic-compatible endpoint (GLM) | no | 3 |

On api.anthropic.com the model calls Bash directly. On the third-party endpoint the model reports Bash was not in its tools and takes an extra turn to reach it, consistent with a tool_search round-trip; the endpoint's tool_search does resolve it, so the beta is implemented, and it re-defers tools the request marked loaded.

Net: the client is not the variable (identical payload). The endpoint decides whether the loaded set stays loaded. api.anthropic.com honors it; at least one third-party endpoint re-defers even the always-load tools. ENABLE_TOOL_SEARCH overriding the non-first-party host-gate (the disable branches are guarded by !process.env.ENABLE_TOOL_SEARCH) is what exposes third-party users to whatever their endpoint does with the beta, with no warning.

One caveat: I logged the request bytes, not the endpoint's raw response, so the re-defer on the third-party side is inferred from the model's observed round-trip rather than read from the response payload.

I find it weird that such a core part of the functionality of this tool has been broken for several months but reverting to an old version (2.1.116) fixed it for me at least, eg

npm install -g @anthropic-ai/claude-code@2.1.116

Found a workaround by looking at the CHANGELOG:

## 2.1.162

- `claude agents --json` now includes `waitingFor` showing what a waiting session is blocked on (e.g. permission prompt)
- `--tools`: explicitly listing Grep/Glob now provides the dedicated search tools on native builds with embedded search (previously these names were silently ignored)

You can enable them by passing it explicitly to the --tools list. Unfortunately this requires passing every other tool too manually :upside_down_face:

# Full tool name list: https://code.claude.com/docs/en/tools-reference
alias claude='claude --tools Agent,Artifact,AskUserQuestion,Bash,Edit,EnterPlanMode,ExitPlanMode,Glob,Grep,ListAgents,NotebookEdit,Read,ReportFindings,ScheduleWakeup,ShareOnboardingGuide,Skill,ToolSearch,Workflow,Write,CronCreate,CronDelete,CronList,DesignSync,EnterWorktree,ExitWorktree,Monitor,PushNotification,RemoteTrigger,SendMessage,TaskCreate,TaskGet,TaskList,TaskOutput,TaskStop,TaskUpdate,WebFetch,WebSearch'

Not having these tools falls back to Bash commands, which requires manual approval. Therefore most users will end up enabling auto mode for convenience, even for tasks that don't require it. I find the removal of these tools to be very irresponsible to say the least, and can't think of a good reason why Anthropic would do this.

Tested on latest version: 2.1.226

Thanks for the detailed reports. I tested this on the released 2.1.233 (macOS native build) and can confirm what you're seeing: Grep and Glob are not in the tool list and ToolSearch select:Grep,Glob returns "No matching deferred tools found".

This is intended behavior, not a tool-search bug (which is why ENABLE_TOOL_SEARCH=false made no difference). Since 2.1.117, native macOS/Linux builds ship with fast search binaries embedded, and find/grep inside Claude's Bash tool are transparently aliased to them — so the separate Glob/Grep tools were removed to save a tool round-trip. You can see it with type grep; type find in a Bash call: both resolve to shell functions. Windows and npm-installed builds are unchanged. See the 2.1.117 entry: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

That said, we agree it's confusing: the tools reference still lists Glob/Grep without mentioning this, and setups that block Bash grep/find to steer toward the dedicated tools end up with no search path. We're treating this as a documentation gap and considering an easier way to keep the dedicated tools.

Workaround today: start Claude Code with --tools Grep,Glob,... (since 2.1.162) to get the dedicated tools back — I verified on 2.1.233 that --tools Grep,Glob,Bash,Read exposes all four. Alternatively, let Bash grep/find through in your hooks on native builds; they are the fast embedded tools.

🤖 Generated with Claude Code

Still reproduces on 2.1.233, and the trigger looks broader than the original report: native install, macOS 26.6, model claude-opus-5[1m], first-party claude.ai host with deferred tools on by default — ENABLE_TOOL_SEARCH is not set anywhere in my settings. So this isn't limited to explicitly opting in on a non-first-party host.

Same shape as reported: Read, Edit, Write, Bash, Agent, Skill, ToolSearch resident; WebFetch, WebSearch, NotebookEdit, Monitor, SendMessage and ~250 MCP tools deferred and resolvable; Glob and Grep in neither list. ToolSearch with select:Glob,Grep,WebFetch returns only WebFetch, which rules out a ToolSearch query problem.

One detail that may explain why they never re-register

Enumerating every tool definition in the shipped binary (grep -aoh -E 'userFacingName\(\)\{return"[A-Za-z]{2,20}"' over ~/.local/share/claude/versions/2.1.233) returns 19 distinct names — and there is no Glob and no Grep definition in the binary at all. There is, however, a Search tool, alongside a CLAUDE_CODE_USE_NATIVE_FILE_SEARCH env var.

That suggests Glob/Grep weren't dropped from the registry so much as replaced by a consolidated Search tool. The gap is that the replacement doesn't arrive: setting CLAUDE_CODE_USE_NATIVE_FILE_SEARCH=1 in the shell did not surface a Search tool in my headless probes, so the session ends up with the old tools gone and the new one gated off — no file-search tool of any kind. Everything falls back to Bash with rg/find, which works but costs a shell round-trip per search, loses the structured output, and quietly ignores the respectGitignore handling the native tools do.

Two things that would help, in rough priority order:

1. If Glob/Grep are intentionally superseded, having Search register whenever they're absent (rather than behind an independent gate) would close the gap — right now the two switches can both be off at once, and nothing tells the user.
2. Failing that, a startup warning when the resolved tool set contains no file-search tool. The current failure is silent, and from the user's side it presents as the model inexplicably shelling out to grep for everything.

Happy to supply the full 19-name list or the surrounding disassembly if useful.

Correction to my comment above — one claim in it was wrong, and the truth makes this report stronger, not weaker.

I said no Glob/Grep definitions exist in the 2.1.233 binary. That was an artifact of how I searched: I grepped for userFacingName(){return"Glob"}. Both tools are present — they've simply had their display name changed. Two distinct tool definitions return userFacingName(){return"Search"}:

// tool 1 — this is Glob
$i({ name: fm, searchHint: "find files by name pattern or wildcard", maxResultSizeChars: 1e5,
     userFacingName(){ return "Search" },
     getActivityDescription(e){ … return t ? `Finding ${t}` : "Finding files" }, … })

// tool 2 — this is Grep
$i({ name: Qf, searchHint: "search file contents with regex (ripgrep)", maxResultSizeChars: 20000, strict: true,
     userFacingName(){ return "Search" },
     getActivityDescription(e){ … return t ? `Searching for ${t}` : "Searching" }, … })

and the two name constants resolve to exactly what you'd expect:

fm="Glob"
Qf="Grep"

So the registered tool names are still Glob and Grep — only the UI label was consolidated to "Search". Grep's schema is intact in there too (mode: content|files_with_matches|count, multiline, head_limit, offset, the [".git",".svn",".hg",".bzr",".jj",".sl"] ignore list).

The important part for this issue: neither definition has an isEnabled(), a shouldDefer, or an alwaysLoad flag. They are unconditionally-enabled tools. There is no feature gate to be off. Yet on my install they appear in neither the resident nor the deferred list, and ToolSearch can't find them by exact name or by description keywords.

What I ruled out on 2.1.233 (native, macOS, first-party host)

| Hypothesis | Result |
|---|---|
| The deferral mechanism drops them | ❌ ENABLE_TOOL_SEARCH=false demonstrably turned deferral off (ListMcpResourcesTool, ReadMcpResource*, WaitForMcpServers, Monitor all became resident) — Glob/Grep still absent |
| Model-specific tool set | ❌ absent on sonnet, opus, and haiku alike |
| Version regression | ❌ 2.1.228 / 2.1.231 / 2.1.232 all ship the same two "Search" tools |
| Managed/policy settings restricting tools | ❌ no managed-settings.json at any of the three macOS paths |
| Missing ripgrep | ❌ the bundled rg shim (ARGV0=rg → the CLI binary) is installed and works |
| Broken settings file silently ignored | ❌ every file in the cascade passes jq empty |
| tengu_non_deferrable_builtins not pinning them | ❌ patching the cached value to {"Glob":true,"Grep":true} in ~/.claude.json changed nothing |
| A Search replacement arriving instead | ❌ CLAUDE_CODE_USE_NATIVE_FILE_SEARCH=1 surfaces no Search tool either |

Everything locally observable says these two tools should register, and they don't — which points at the tool list resolved for the account/session rather than at client code or local config. Since tengu_deferred_stub_tool is true and tengu_non_deferrable_builtins is {} on my install, my guess is that builtins with no shouldDefer flag fall between the two buckets when deferral is active, but I can't confirm that from the outside.

Two asks, unchanged in substance from my earlier comment:

1. A startup warning when the resolved tool set contains no file-search tool. Right now the only symptom is the assistant silently shelling out to grep/find for every search, which reads to the user as the model degrading.
2. Since the tools are ungated in code, a supported local override to force builtin registration would make this self-serviceable instead of a wait-for-the-server situation.

Apologies for the noise from the incorrect first claim — happy to run further probes on this install if it helps narrow it.

Adding a data point that doesn't match the "removed on native builds" explanation above — this looks like it's the same underlying gap @mszyma found (tools present, unconditionally enabled, just not resolving), but triggered a different way.

Confirmed on Claude Code CLI 2.1.239: custom subagents never receive Grep/Glob in their resolved runtime tool schema, regardless of how the agent's tools: frontmatter is written — explicit tools: Bash, Read, Grep, Glob, ... in the agent file makes no difference, they're simply absent at runtime. Built-in agents (e.g. Explore, Plan) are unaffected and resolve them normally. This isn't native-build-specific in our case and doesn't look like the bfs/ugrep Bash-aliasing behavior described upthread (see also #52476, which found that changelog note wasn't actually the explanation) — it's specifically the custom-subagent resolution path that drops them, which lines up with @mszyma's finding that both tools are present in the binary, unconditionally enabled, with no isEnabled/shouldDefer gate, but aren't showing up resident or deferred.

Cross-referencing the two earlier reports of what looks like the same root issue: #52004 (closed completed, but multiple commenters report it persisting well after the fix landed) and #52055 (closed as a duplicate of #52004/#51921).

Happy to share our subagent config / repro steps if useful for narrowing this down.