[BUG] tool_search_tool_regex and ToolSearch appear to coexist as duplicate tools, inflating baseline System Tools token cost

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest related: #90113 and #81620, but both describe token miscounting, not tool duplication)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (confirmed via claude update)

Environment

• Claude Code version: 2.1.260 (confirmed latest, claude update reports "up to date")
• Platform: macOS (Darwin 25.6.0), arm64
• Model: claude-sonnet-5

What's Wrong?

Running /context shows a fixed "System tools" category (non-deferred, always loaded) weighing 28.4k tokens for only ~7 top-level tools (Bash, Read, Edit, Write, Skill, ToolSearch, and a tool exposed as tool_search_tool_regex).

tool_search_tool_regex (description: "Searches for functions") and ToolSearch (the deferred-tool lookup mechanism, described as "Fetches full schema definitions for deferred tools...") appear to serve the same purpose — searching/resolving tool schemas — but both are present simultaneously in the same session's always-loaded tool set. This looks like a leftover/duplicate from a naming migration (tool_search_tool_regex → ToolSearch) rather than two intentionally distinct tools.

Since "System tools" is always loaded (not deferred), this duplication adds a fixed token cost to every single turn of every session, for every user who has both registered, with no way to opt out.

Why this is a problem for us

We were auditing per-session token overhead (trying to reduce fixed costs after disabling several MCP connectors). We found:

• No config file, settings.json option, or permission rule can remove or hide a built-in tool's schema from context — permission deny rules only block invocation, not the schema/token cost.
• The binary at ~/.local/share/claude/versions/2.1.260 is compiled (Mach-O), so there's no local file we can edit to trim or merge these definitions ourselves.
• We're already on the latest version, so an update doesn't resolve it.

This leaves affected users with no way to reduce this part of their fixed per-turn overhead, even though the duplication looks unintentional.

What Should Happen?

Either:

1. tool_search_tool_regex should be fully retired/removed now that ToolSearch exists and serves the same function, or
2. If both are intentionally kept (e.g., different resolution strategies), their descriptions should be deduplicated/compacted so the redundant capability doesn't double the fixed token cost, or
3. Expose a supported way (e.g., a settings.json flag) to disable specific built-in tools from being loaded into context for users who don't need them.

Steps to Reproduce

1. Start a fresh Claude Code session on 2.1.260.
2. Run /context all.
3. Observe both tool_search_tool_regex and ToolSearch present as separate, always-available top-level tools contributing to the non-deferred "System tools" total.