Composer @ picker: prioritize working threads among equally strong title matches

[brandon-julio-t]

Problem in daily use

I run several threads in parallel and use the composer’s @ picker to reference one conversation from another. Right now it is frustrating enough that I keep getting interrupted while trying to write a prompt: a thread visibly working in my sidebar can be absent from the suggestions, or appear below a settled thread, even when both titles match the word I typed equally well.

Two examples from my actual session, with project details omitted and titles simplified:

• I typed @investigate to reference a currently working “Investigate Scheduled Refresh…” thread. The picker showed five other “Investigate…” threads and then file results. The thread I wanted was right there in the Working sidebar, but missing from the picker.
• I typed @replace to reference a currently working “Replace Query String Usage” thread. A settled “Replace analytics text search…” thread ranked above it. Both titles start with “Replace,” so the ordering did not reflect the work I was doing at that moment.

These are not hypothetical examples. I had to stop composing, inspect the results, and think of a different single word to retrieve a conversation I could already see on screen. It makes referencing ongoing work feel unnecessarily difficult.

Screenshots from the actual session

Missing working thread: @investigate lists five other threads, but omits “Investigate Scheduled Refresh…” even though it is visibly working in the sidebar.

Working thread ranked second: @replace puts “Replace qs Query String Usage” below a settled analytics thread. The target's Working state is visible in the sidebar. The first result's settled state is from my session; the picker does not show status.

Screenshots retain the original layout, result order, and arrows. Project identifiers, repository paths, conversation text, and an unrelated task title are redacted.

Why it is hard to recover

The composer returns at most five thread matches. Adding a second word closes the picker because of the existing space bug (#15156; proposed fix #15157). So when the first word is common across my task titles, I cannot naturally narrow the query or browse the remaining thread matches. File results are still available, but they do not help me reference the missing conversation.

Proposed direction

Could the composer’s @ picker favor threads in Working over settled threads among comparably strong title matches, and use recency within those matches? An exact full-title match should still beat a weaker match regardless of whether the thread is settled. Settled conversations should remain searchable and referenceable.

I am proposing a direction for discussion, not asserting that status must override every other relevance signal. The important outcome is that referencing current work should be easy when several thread titles share a common first word.

The five-result limit and inability to type spaces amplify this problem. Fixing spaces would help, but I would still like the ordering to account for the context of ongoing work.

Relation to recent search work

#24343 changed composer thread matching from title-substring matching ordered by update time to the shared relevance/use scorer. Current source does not explicitly prioritize Working over settled threads. That is a possible explanation for the behavior I am seeing; I have not established a controlled before/after regression on my installed client.

I did not find an existing discussion specifically covering Working-versus-settled priority in composer mentions. #15157 addresses spaces, and #25478 proposes interpreting separators as spaces for thread queries; neither addresses this ordering preference.

— Brandon Julio Thenaro

Prepared with GPT-6.1-Sol through Codex in T3 Code.

[guryanov-a]

Another case from 0.1.6 on macOS. It adds two things to the proposal here.

In a new thread I typed @con to reference "Continue M7 Command Burst Milestone", a thread in the same project. It wasn't running: it had finished a few hours earlier but was still unsettled. The picker returned:

1. Claude Config Review: Strapi, Socio
2. Application Center Page Missing Content
3. Fix /machines 503 from uiLabels content error
4. Subagent Usage and Context Limits
5. Continue M7 Command Burst Milestone

The only title that starts with the query came last, one slot from being cut by the five-result limit.

The cause looks like the prefix score in matchToken, 0.7 + 0.2 * token.length / wordLength (paletteSearch.ts#L222). For con it gives Config 0.800, Content and Context 0.786, and Continue 0.775. So a longer matching word loses, and the word's position in the title doesn't count. The usage boost then multiplies these near-equal scores.

Two additions to the proposal:

1. Title-start match first. Among prefix matches, a query that matches the beginning of the title should outrank a match on a later word. People type the start of the title they see in the sidebar.
2. Unsettled threads too, not only Working ones. The thread I wanted had finished but was still unsettled, so it was still on my active list. If the tie-break treats unsettled threads like Working ones, it covers this case as well. Settled threads stay searchable.

Either change alone would have put this thread first. The workaround is to type the whole word: @continue is a whole-word match and scores 1.0. That defeats the point of autocomplete, though, and because of #15156 I can't type a second word to narrow the results instead.