[BUG] Slash-command autocomplete blends unfiltered global history.jsonl entries into unrelated queries

Description

The / slash-command autocomplete menu blends ~/.claude/history.jsonl (a global, cross-project, cross-session log of every previously submitted input) into its suggestions, apparently ranked by recency/frequency — but without filtering those history-derived rows by the text currently being typed. This causes a frequently-used command from an unrelated project/worktree to dominate the dropdown even when typing a completely different, non-matching command name.

This is a different mechanism from the duplicate-registration bugs already reported (#82368, #66003, #44030, #42384): those are about a single skill/command being registered more than once (plugin duplication, rendering dedupe failure). Here there is exactly one registration each for the command and the skill involved — the extra rows are literal history log entries being re-surfaced.

Steps to reproduce

1. Over several sessions/projects, submit a bare slash command many times, e.g. type /review-pr and press enter repeatedly across different sessions (in my case: 6 times, across 2 different git worktrees of the same repo, over several days).
2. In a new session, start typing an unrelated slash command that shares no meaningful characters with the frequently-used one — e.g. /refine (note: "review-pr" and "refine" share no common letters relevant to a prefix or reasonable fuzzy match: no f, no n in "review-pr").
3. Observe the autocomplete dropdown.

Expected behavior

The dropdown should only show commands/skills whose name plausibly matches the typed text /refine — e.g. /refine, /refine-card, maybe fuzzy near-misses. History should, at most, influence ordering among actual matches, not inject unrelated entries.

Actual behavior

Typing /refine shows /review-pr repeated ~8 times (verbatim, identical description text each time), interspersed with the 2 actual matches (/refine, /refine-card) and another unrelated command (/doc-gap). None of the /review-pr rows relate to the typed text in any way.

Cross-checking against ~/.claude/history.jsonl: it contains exactly 6 lines where display is the bare literal string "/review-pr", submitted from 2 different project worktrees over the preceding several days — none from the current session. This count (plus the one live command-registry entry) accounts for the repeated rows seen in the dropdown, confirming the history file is the source.

A related, milder version of the same bug: typing /review-pr itself (i.e., typing the matching prefix) also shows the command 5x — 1 live registration + duplicate history rows — even though in that case the text does match, so it's harder to notice without checking the history file directly.

Environment

• Claude Code version: 2.1.220
• OS: Linux (WSL2), 6.18.33.1-microsoft-standard-WSL2, x86_64
• ~/.claude/history.jsonl present with 4364 total lines at time of investigation, spanning many projects/worktrees

Suggested fix

Either:

• Filter history-derived autocomplete rows by the currently typed prefix/fuzzy-match, same as live registry entries, or
• Deduplicate history-derived rows against each other (collapse repeats of the same bare command to one, most-recent-timestamp entry) and against the live registry entry for that same command/skill, or
• Scope the history blended into the menu to the current project, not the global cross-project log (separately debatable, but would have reduced this instance's severity).