[FEATURE] /pr_comments ranks higher than /commit when typing /com - improve fuzzy matching, enter selects unexpected command and allow disabling built-in commands

+1. IMHO, first prefix match against an alphabetically sorted list of /commands is probably the best option.

From ~~#11573~~:

/com<tab> improperly selects the slash command /pr-comments instead of /compact - Tab should always perform a proper prefix match. This is an important issue because compact is used frequently, and keyboard shortcuts are important to developers.

To me the biggest offender is highlighting equally 2 commands, and the one appearing on top not being the one selected.

It is very bad UI design, so easy to fix.

@adriangalilea what version are you on? I can't repro on latest.

@adriangalilea what version are you on? I can't repro on latest.

version: 2.0.53

Most of the issues have been fixed, and now at least is not confusing as there’s no 2 highlighted items.

But it's mildly frustrating still:

<img width="746" height="176" alt="Image" src="https://github.com/user-attachments/assets/cd8ff7b4-f945-491e-ae17-6d7a033a6694" />

• If com is typed, the ones starting by com should rank first.
• Frecency (zoxide-like) can be introduced as well, I have never used pr-comments and I used commit a million times, so even writing c should rank it first, but it may be unexpected for some.
• I would like to disable commands I don't use such as pr-comments

you can replace "pr-comments" with "zuselesscrap" in cli.js until it's fixed

I've been trying to remove pr-comments because I have exactly the same /commit command and it happens to me too.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This is still an issue if it's not been addressed by someone at Anthropic.

I'm hitting this issue with /plugin being overshadowed by /plugin-dev:create-plugin from the official claude-code-plugins marketplace.

When I type /plugin:

• /plugin-dev:create-plugin is highlighted/selected (plugin command)
• /plugin appears below it (built-in command I want)

Pressing Enter executes the wrong command. This is particularly problematic because plugin commands are hiding built-in commands - I can't access the core /plugin management command without arrow-keying past the plugin command.

Exact matches should always rank first, especially for built-in commands.

Recent Regression Reports (Jan 17-18, 2026)

This issue appears to have regressed or worsened significantly. 5+ duplicate reports in the past 48 hours all describing the same symptom:

Visual Recreation

❯ /cont█
─────────────────────────────────────────────────────────────
  /context    Visualize current context usage as a colored grid
▶ /compact    Clear conversation history but keep a summary...   ← HIGHLIGHTED (wrong!)
  /config     Open config panel
  /clear      Clear conversation history and free up context

Even typing the complete command /context + Enter executes /compact:

❯ /context█
─────────────────────────────────────────────────────────────
  /context    Visualize current context usage as a colored grid   ← EXPECTED
▶ /compact    Clear conversation history but keep a summary...    ← ACTUALLY SELECTED
  /clear      Clear conversation history and free up context

Root Cause Hypothesis

The selection index operates on the unfiltered command list rather than the filtered results. When you type a prefix, the menu filters correctly but the highlight remains at index N of the original list.

---

Recent Duplicate Reports

| Issue | Date | Platform | Typed | Selected | Version |
|-------|------|----------|-------|----------|---------|
| #17816 | Jan 17 | Windows | /resu | /o365 | v2.1.5 |
| #18832 | Jan 17 | macOS | /context | /preflight | — |
| #18902 | Jan 18 | macOS | /status | /statusline | v2.1.12 |

Key Observations Across Reports

• Filtering works — matching commands appear in the dropdown
• Selection is offset — highlight stuck on wrong index
• Affects all platforms — macOS, Windows, Linux reported
• Recent versions — v2.1.5 through v2.1.12 confirmed affected
• Workarounds: Press ↓ arrow to manually select, or add trailing space (/context )

---

This is breaking muscle memory and causing unintended command execution for many users. The volume of recent reports suggests a regression in the v2.1.x release line.

Still an issue... Any resolution incoming? I began seeing this when I added a lot of skills. Probably breaking at a certain limit. Will repro

This is a really frustrating.

This command ranks high in my slash commands and not having the ability to control all of the slash commands that appear on my machine is a pretty poor user experience.

Hoping this is addressed soon.

Adding a small data point in support of the "allow disabling built-in commands" part of this request. I ran into /stickers unintentionally today, and it opens a page in the browser when invoked. It's a harmless built-in, but it's also one I'll probably never use, and there's no way to remove it from my command surface. A settings.json option to allow-list or deny-list specific built-in commands would let teams tailor the command namespace to their actual workflow without affecting anyone else. Happy to help test if useful.

Adding a concrete data point + arguing for severity re-classification.

Repro on v2.1.148 (100% reproducible)

1. Have a skill installed (in my case claude-md-lint).
2. Type /clean (typo of /clear) and press Enter — no Tab, no menu interaction.
3. The claude-md-lint skill is launched as a sidechain agent and runs to completion. No confirmation, no menu, no error.

Session JSONL evidence: a user message records the prompt with no <command-name> block, and the same promptId appears on a sidechain agent JSONL whose first line begins with Base directory for this skill: ~/.claude/skills/claude-md-lint. Proves single-hop silent expansion — Enter is both submit and commit; the resolved target is invisible until execution has already started.

Why the current "High / productivity" label likely understates this

The mechanism is "Enter on a non-exact slash command silently executes the fuzzy-resolved target." The blast radius of that execution is whatever skill the matcher picks, which is a function of the user's installed skill set — i.e., arbitrary and unbounded by Claude Code's own design.

Skills can, by their normal contract:

• Mutate project files (Write / Edit)
• Execute shell commands (Bash)
• Send to external services (Slack, GitHub, deploy webhooks)
• Fork expensive LLM contexts
• Commit to git, open PRs, post comments

None of those side effects can be reasoned about by Claude Code itself, because skills are user-installable. The question "what does /<typo> do?" has the answer "anything — we cannot say." That is the shape of an arbitrary-action-on-unintended-input bug, which in most CLI tooling is classified as a safety/security issue rather than a productivity one.

Why this is not already covered by the closed cousins

• #40931 (NOT_PLANNED) scoped the concern to /clear. Its blast argument was bounded — losing context. The argument here is unbounded — losing anything the nearest-named skill happens to be authorized to touch.
• #19107 (NOT_PLANNED) framed it as a UI selection bug (menu highlight wrong). The argument here is the opposite: there is no UI in the failure path. The user never sees a menu to be misled by; they type and press Enter, period.

Request

• Please consider re-labeling this issue from a productivity concern to a safety / security concern.
• Minimum fix that addresses the safety axis specifically: Enter on a non-exact slash command must never silently commit a fuzzy resolution. Either reject with Unknown command: <typed>, or require explicit Tab / Arrow + Enter through the menu to confirm a non-exact target.
• The existing productivity proposals in this issue (frecency ranking, prefix prioritization, disabling built-ins) remain valuable, but are additive to the safety minimum, not substitutes.

Environment: claude 2.1.148, Linux WSL2.

+1

There's no way to disable or hide unwanted built-in commands

I am more interested in disabling some built in commands. Concrete pain point: /usage-credits sits adjacent to /usage in the picker. Every accidental hit fires "Request sent to your admin to turn on usage credits." Admin on my team is getting spammed with these requests from users who meant to type /usage.