[FEATURE] Make ToolSearch activity visible in the UI like other tool calls

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

ToolSearch tool calls are completely invisible in the CLI interface. While other tool calls (Read, Bash, Edit, etc.) are displayed with their name, parameters, and results, ToolSearch calls produce no visible output at all — not even a brief notification. The user sees nothing.

This became a significant issue in v2.1.69, which extended ToolSearch deferral from MCP tools to all built-in system tools (Bash, Read, Edit, Write, Glob, Grep, Agent, etc.). Now every session begins with multiple ToolSearch calls to load basic tools, but users cannot see this happening.

Concrete experience: After updating to v2.1.69, I noticed my sessions behaving differently but could not determine why. I only discovered that ToolSearch was being used — and that all built-in tools were now deferred — through a conversation with Claude itself. Another user (#31013) discovered it only through packet capture. The UI gave no indication that this mechanism was in play.

When a user cannot see what their agent is doing, they cannot:

• Understand why a session feels slower at startup
• Debug issues when tool loading fails
• Make informed decisions about context budget (ToolSearch calls consume tokens too)
• Trust that the agent is working as expected

Proposed Solution

Display ToolSearch tool calls with the same visibility as other tool calls. At minimum, show:

• That a ToolSearch call was made
• Which tools were loaded as a result

This does not need to be as verbose as a Bash call. A collapsible/expandable display would work well — compact by default, but expandable for users who want to see the details. The key point is that it should not be invisible.

Example (compact):

ToolSearch  Loaded: Bash, Read, Edit

Example (expanded):

ToolSearch("select:Bash,Read,Edit")
  Loaded 3 tools (2,847 tokens added to context)

Alternative Solutions

• ToolSearch calls are currently completely hidden from the user, presumably to reduce visual noise. This may have been acceptable when ToolSearch only applied to MCP tools (a niche feature). But with all built-in tools deferred in v2.1.69, ToolSearch calls happen in every session and complete invisibility becomes a real problem.
• ENABLE_TOOL_SEARCH=false can disable the feature entirely, but this sacrifices the token savings (~13-15k tokens per session). Users should not have to choose between efficiency and visibility.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

1. User updates Claude Code to v2.1.69
2. Session startup feels different — a slight delay before Claude begins working
3. User checks /context and sees "System tools: 968 tokens (0.5%)" but doesn't know what this means or that it changed
4. User has no way to know that ToolSearch is loading tools on-demand behind the scenes
5. If a ToolSearch call fails (e.g., DAC unavailability as in #30516), the user sees a cryptic error with no context about what was being attempted

With visible ToolSearch calls, step 4 becomes: user sees "ToolSearch: Loaded Bash, Read, Edit" and understands the mechanism. Step 5 becomes: user sees "ToolSearch failed" and knows where to look.

Additional Context

Related issues:

• #31002: Built-in system tools now deferred behind ToolSearch (undocumented change) — requests documentation and controllability
• #31013: ToolSearch causing unnecessary multiple rounds of conversation — requests design change to pre-load core tools
• #30516: ToolSearch blocks all deferred tool access when DAC is temporarily unavailable — the failure mode is worse when users can't see what's happening

This issue complements #31002 and #31013. They address what changed and whether it should change; this addresses how it's presented to the user.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)