@mention picker includes duplicate out-of-channel agents and moves while selecting

[jialudev]

Important

Do not include security vulnerabilities in a public issue. Report them
privately through a GitHub security advisory.

Describe the bug

In a channel or thread composer, the @ mention picker mixes current channel members with agents that are not in the current channel. When multiple agent identities use the same display name but have different pubkeys, they appear as several nearly identical rows.

The list also repeatedly reorders and/or scrolls while it is open. The target moves while I am trying to select it, so it is difficult to mention the intended person or agent. The combination of channel members, out-of-channel agents, duplicate names, and a moving list is very confusing.

Steps to reproduce

1. Have multiple agent identities with the same display name but different pubkeys; at least some of them are not members of the current channel.
2. Open a channel or thread composer.
3. Type @ (or open the mention picker).
4. Observe that several same-named agents marked agent · not in channel are mixed into the list.
5. Keep the picker open and try to scroll or select a result.
6. Observe that the candidates reorder and/or the list scroll position changes, causing the intended target to move.

Actual behavior

• Out-of-channel agents are mixed with current channel members.
• Different agent identities with the same display name are hard to distinguish; the pubkey suffix is not a useful primary discriminator for most users.
• The list moves while the user is interacting with it, making both pointer and keyboard selection unreliable.

The blue outline highlights examples of the confusing duplicate, out-of-channel agent rows:

Expected behavior

• Keep the candidate order and scroll position stable while the picker is open. If data refreshes, preserve the selected item by its stable identity.
• Prioritize current channel members and do not mix out-of-channel agents into the main list. Hide them by default, show them only after an explicit search, or place them in a clearly separated Other agents section.
• If separate same-named agent identities must remain selectable, show a stable, human-readable discriminator such as channel membership, runtime/setup, owner, or status. The pubkey can remain secondary detail.
• It should be easy to select the intended person or agent without the target moving.

Is showing every locally managed agent even when it is outside the current channel intentional? If so, the picker still needs clearer grouping and a stable interaction model.

Version and platform

• Buzz version: unknown (browser-hosted UI)
• OS: macOS, Chrome

Logs / additional context

No relevant logs.

Possibly related:

• Desktop: @-mention autocomplete surfaces archived and profile-less orphan identities #7251 — identities that should not be mention targets appear in the picker
• [Bug] Second Desktop install creates duplicate agent identities, inflating channel membership #2648 — multiple same-named agent identities with different pubkeys

This issue focuses on the user-facing mention-picker confusion and selection instability, even if keeping distinct pubkey identities is intentional.

[PresentJay]

Tried to reproduce this against origin/main in the desktop E2E mock
environment. Splitting what I could and could not see, since the three
symptoms behave differently.

The list did not move

I opened the picker in a channel composer and sampled the rendered candidate
list six times over 4.5 s without touching it. The set and its order were byte
-identical at every sample — no reorder, no scroll shift.

That is the symptom that actually makes the picker hard to use, so it is worth
saying plainly that my environment does not have whatever triggers it. The mock
has a small fixed roster with profiles already resolved, so anything driven by
late-arriving kind:0 profiles, agent-directory refreshes, or presence updates
would not fire here.

Could you say roughly how many agents and members the channel had, and whether
the reorder happens on first open or only after the picker has been open for a
moment? That would narrow it to a specific late-arriving source.

Out-of-channel agents look deliberate rather than accidental

They do appear — I see charlie · agent · not in channel mixed in with channel
members. But notInChannel is an explicit field on the suggestion and
MentionAutocomplete.tsx renders a dedicated label for it, so including them
and marking them reads like a decision rather than a leak.

If the ask is to rank them below channel members, or to hide them behind a
filter, that is a UX change on top of an intentional behaviour rather than a
bug fix — probably worth stating as such so it can be judged on its own terms.

Same-name disambiguation already has a mechanism

MentionAutocomplete.tsx computes hasNameCollision and, when it is set,
renders safeNpub(suggestion.pubkey) next to the name specifically so identical
display names can be told apart.

So either that path did not trigger for your duplicates, or it did and the
truncated npub was not enough to tell them apart in practice. Those are
different problems with different fixes. Do you remember whether the rows showed
an npub1… suffix at all?

---

Not disputing the report — I cannot reproduce the movement, which is the part
that matters most, and the details above would tell us whether it is a distinct
bug from the other two.

[BTCNautilus]

Root cause from the source — and I think the missing repro precondition is why the E2E mock didn't show it.

The candidate universe is the entire local managed-agent registry, unscoped by community/relay. desktop/src/features/messages/lib/useMentions.ts builds its mention candidates from useManagedAgentsQuery() (the full managed-agents.json), and mentionCandidates.ts turns each record into an identity candidate keyed by pubkey. There is no filter by the active channel's community/relay and no dedupe by persona/display-name, so every managed-agent record on the machine is offered in every channel's picker — including agents that belong to a different community and are not members here (they render as agent · not in channel).

Why the duplicates specifically appear (the precondition to reproduce): the built-in welcome swarm (fizz/honey/bumble personas) is minted per-relay. If you belong to two communities that each provision a welcome team, you end up with two records that share the same persona and display name but have different pubkeys — e.g. two "Keeper"s, one per relay. Both live in managed-agents.json, so both surface in the picker in every channel, regardless of membership. A single-community fixture never hits the collision. To reproduce: provision welcome teams in two communities on two relays, then open any channel's @ picker.

This compounds with #5488 (stale identities accumulate in managed-agents.json when the relay URL changes) — that's the source of the duplicate records; this issue is that the picker then surfaces them everywhere. Deleting a stray record does not durably help, because the community re-mints it on the next channel-add.

Suggested fix direction (matches the Expected behavior above):

• Scope managed-agent mention candidates to the active channel's community/relay; do not mix out-of-channel agents into the main list (hide behind explicit search, or a clearly separated "Other agents" section).
• Dedupe candidates by pubkey; when same-name / same-persona records remain, show a stable discriminator (community/relay), not the pubkey suffix.

(Read against 76aeae70; paths may have shifted on newer builds.)