Bug Description

Claude Code feedback

Title: Tab in slash-command autocomplete should complete to longest common prefix (readline-style), not full-accept the highlighted entry

Problem

In the slash-command/skill autocomplete menu, Tab (autocomplete:accept) immediately inserts and accepts the highlighted entry. When the typed prefix is ambiguous, this jumps to whatever's highlighted first — often not what I want.

Example: I have the claude-reflect plugin (commands reflect, reflect-skills, view-queue, skip-reflect). Typing /claude-ref + Tab completes all the way to /claude-reflect:view-queue — a command I almost never run — instead of stopping at the shared prefix.

Requested behavior

Make Tab complete to the longest common prefix of the remaining candidates and keep the dropdown open, like readline/shell tab-completion:

• /claude-ref + Tab → /claude-reflect: (common prefix of all matches), menu stays open.
• Next Tab (or more typed chars) narrows further; Tab only full-accepts once a single candidate remains.

This is especially valuable for namespaced plugin commands (plugin:command), where the namespace is the natural common-prefix stopping point.

Possible implementation

• Add a distinct action (e.g. autocomplete:completePrefix) bindable in the Autocomplete context, OR
• Change autocomplete:accept to do prefix-completion when multiple candidates match and full-accept only when one remains.
• Add an option to configure stop separators (e.g. [':', '-']) so that Tab stops at the separator boundary.

Workaround today

None exact — currently must type past the ambiguity or arrow-key to the target before Tab. The keybinding action set only exposes full-accept.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.165
• Feedback ID: cbedafd8-d056-44a7-9d3a-3ec600dfac58

Errors

[]