[Bug] "Tool loaded." output from ToolSearch appears as user prompt (regression in 2.1.70)

Status Fixed / completed
Reported on v2.1.70
Maintainer reply ✓ Yes — blois
Activity 5 comments · opened Mar 6, 2026 · closed Mar 6, 2026
💡 Likely answer: A maintainer (blois, collaborator) responded on this thread — see the highlighted reply below.

Summary

Since 2.1.70, when deferred tools are loaded via ToolSearch, each successful load displays ❯ Tool loaded. in the terminal. This is a regression — before deferred tool loading was introduced, all tools were preloaded silently.

Current Behavior

  • Every ToolSearch call produces a visible ❯ Tool loaded. line in the conversation
  • The message renders with the user prompt prefix (), making it look like something the user typed
  • The message gets picked up as the session name, which is clearly unintended

Expected Behavior

Tool loading should be silent or at minimum not appear as a user prompt. Options:

  • Hide these messages entirely (they're infrastructure, not user-facing results)
  • Collapse into a single summary line (e.g., "3 tools loaded")
  • Render as system output rather than with the user prompt prefix

Context

This was introduced in 2.1.70 with the deferred tool loading feature. Before that, all tools were preloaded and no such message existed.

View original on GitHub ↗

5 Comments

tnlanh · 5 months ago

I encountered the same issue. The “Tool loaded.” message often became the session name for some reason.

silverwind · 5 months ago

This is a regression introduced in 2.1.70. It's very confusing because it looks like a user prompt.

KartikPawade · 5 months ago

Root Cause Analysis

Having dug into this, the regression likely stems from how the ToolSearch deferred loader emits its confirmation message. Before 2.1.70, all tools were preloaded silently at startup with no user-visible output. The deferred loading feature introduced a "Tool loaded." emit, but it appears to be going through the same rendering pipeline as user prompt messages — hence the prefix and the session name side-effect.

There are two likely root causes:

  1. Wrong output channel: The message is written to stdout (or the shared TUI message stream) instead of an internal stderr/system log channel.
  2. Wrong message classification: The message may be tagged with a user-role type, causing the TUI renderer to apply the user prompt prefix () and include it in session-naming logic.

Proposed Fix

The fix should be applied at the point where ToolSearch emits its success confirmation:

  • Option A (Preferred): Suppress the "Tool loaded." message entirely. Tool loading is infrastructure, not user-facing output. Silent success is the right UX here — consistent with pre-2.1.70 behavior.
  • Option B: Route the message to a system-classified output type (not user), so the TUI renderer skips the prefix and the session namer ignores it.
  • Option C: Batch all tool load events and emit a single summary (e.g., 3 tools loaded) as a system-type message at the end of the initialization phase.

Secondary Fix: Session Naming

The session naming logic should be hardened to only consider user-role messages that originate from actual user input, not from tool/system infrastructure. Adding a source flag (e.g., source: 'user_input') to user messages and filtering on that would prevent this class of bug from recurring.

Steps to Reproduce

  1. Install Claude Code 2.1.70+
  2. Start a new session that triggers a ToolSearch deferred tool load
  3. Observe ❯ Tool loaded. appearing in conversation output
  4. Check session name — it may be set to "Tool loaded."

Happy to help test a fix or contribute a PR if the relevant source is accessible.

blois collaborator · 5 months ago

Fix should be landing in next version.

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.