[FEATURE] @-file picker: Tab should complete to the longest common prefix, not full-accept the top match

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

Request

In the @-file reference picker, make Tab extend the typed text to the longest common prefix (LCP) of the current matches and keep the menu open, instead of full-accepting the highlighted entry. This is standard readline/shell completion behavior.

Why this matters

Tab-completing to the common prefix is decades-old muscle memory from every shell. The current "Tab accepts the highlighted item" model doesn't scale: when a prefix matches many files, the only way to reach the one you want is arrow-cycling through the list one item at a time. With 10+ matches that's a real burden, and it defeats the purpose of autocomplete — which exists precisely so you don't have to press Down N times.

Scope

This is specifically about the @ file-path picker's Tab behavior. Keeping the existing Enter-to-accept and arrow-navigation is fine — this only asks Tab to do LCP extension.

Prior issues

This was previously raised and closed. #62579 ("tab-completion mode similar to bash") was closed NOT_PLANNED; #65743 was closed as a duplicate of it; #12488 was auto-deduped into the unrelated #8399 (a Tab-triggers-thinking regression). None of those resolved the actual request, so re-filing scoped narrowly to the @ picker's Tab = LCP behavior. In fact, I doubt that anyone is ever going to read this.

Proposed Solution

On Tab with an ambiguous prefix: extend the input to the longest common prefix of the current candidate set and keep the dropdown open; do not accept. Accept (existing behavior) only when the candidate is unique, or via Enter / an explicit selection. Optionally expose this as a bindable action (e.g. autocomplete:complete-prefix) so it can be mapped in keybindings.json.

Alternative Solutions

• Pluggable completion provider ("pass-through" tools): a config hook where the user registers an external completion command for the

input line (fzf, a custom script). The editor shells out and inserts the result. This solves LCP and every future completion complaint in one general mechanism.

• Bindable-action-only: at minimum ship autocomplete:complete-prefix as a keybindings.json action, even if it isn't the default.

• Compositor-level workaround (what users resort to): a window-manager hotkey runs fzf over the cwd and synthesizes keystrokes

(wtype/ydotool) to type the path at the cursor. Works, but shouldn't be necessary to get shell-standard completion.

• Patching the shipped binary ("decompile"): the CLI now ships as a Bun-compiled single executable (npm bin is claude.exe too), so users

wanting this have to extract the embedded bundle, rewrite the minified accept handler, and rebuild — then reapply on every release (currently ~daily). That anyone would reverse-engineer a 215MB binary for Tab completion is itself evidence the gap is worth closing upstream.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

Directory with: twig_logo_250x250.png, "Twig building map.pdf", "TWIG ... AGREEMENT.md" (several copies), "Twig quality score.pdf", etc, into the hundreds.

Type: @~/Downloads/twig Press Tab.

Observed: the top match is fully accepted; I'm locked onto one arbitrary file. Expected: the input extends to the longest common prefix shared by all matches (here twig) and the menu stays open, so I can type one more character (_) to disambiguate. Nothing is accepted until the match is unique or I explicitly pick one.

The matching is also fuzzy/substring rather than prefix, which surfaces unrelated files and makes LCP completion more valuable, not less.

Additional Context

_No response_