Mention autocomplete hides agents that are channel members but managed by another install

[xoxoskeleton]

Setup. Two people, two Macs, one shared channel. One person runs agents Scout and Emmy on their Mac. The other runs agent Prinny on theirs. All three publish kind:0 profiles, are members of the channel with role bot, and are configured respond_to: anyone.

Expected. Each person can @ any agent in the channel.

Actual. Each person's mention autocomplete offers only the agents managed by their own install. Neither can reach the other's agents from the GUI at all, because a mention with no resolved pubkey carries no p tag, and the p tag is what wakes an agent.

Cause. In desktop/src/features/messages/lib/useMentions.ts:249, every candidate passes through:

if (!isAgentIdentityInManagedList(candidate, managedAgentPubkeys)) {
  return;
}

managedAgentPubkeys is derived solely from useManagedAgentsQuery() (useMentions.ts:163), which calls the list_managed_agents Tauri command. That command reads local disk records only (desktop/src-tauri/src/commands/agents.rs:524 -> load_managed_agents). So any candidate with isAgent === true whose pubkey is not a locally managed agent is dropped before anything else runs.

This appears intentional: agentAutocompleteEligibility.test.mjs:139 asserts it as "keeps people and only current managed agent identities".

Why it looks worth revisiting. The permissive path for exactly this case already exists and is currently unreachable for remote agents:

• getMentionableAgentPubkeys (agentAutocompleteEligibility.ts:33) already unions locally managed agents with relay-directory agents that pass relayAgentIsSharedWithUser (respond_to: anyone plus a shared channel, or an allowlist naming the current user).
• shouldHideAgentFromMentions (agentAutocompleteEligibility.ts:67) already has a documented "Option B" branch for member agents, showing them unless the kind:10100 directory explicitly excludes the current user.
• useMentions.ts:334 iterates relayAgentsQuery.data and adds those agents as candidates.

All three are gated out by the managed-list check that runs first, so a remote agent can never reach them.

Proposed change. Let the managed-list check admit agents that getMentionableAgentPubkeys already considers invocable, i.e. run the eligibility test before the ownership test rather than after. Concretely, drop an agent identity only when it is neither locally managed nor in mentionableAgentPubkeys. The invocability signal (respond_to plus shared channels, via kind:10100) is the right authority for this, and it is already computed.

Impact. Without this, multi-person multi-agent collaboration in a shared channel only works if every human relays through their own agent. That works, but it means a human can never directly address a teammate's agent.

Verified against: upstream main @ b1b283c, desktop 0.5.3.

Related: #4487 / #4488 (same two-Mac setup, separate respond_to propagation bug).

[xoxoskeleton]

Counter-evidence from my own setup, posting it rather than leaving the report standing unqualified.

Today the other person's agent did appear in my picker, and selecting it produced a correctly addressed message: the sent event carried ["p","def832…69d0"], the real remote agent's pubkey, not a local clone's.

I cannot reconcile that with the code. The gate at useMentions.ts:249 is still present and unchanged at current main (d4a4570), it sits inside addCandidate so every loop including the relay-directory loop at :334 passes through it, and the agent in question has channel role bot, which sets isAgent: true in the member loop and should therefore fail isAgentIdentityInManagedList.

Most likely explanation is that the shipped desktop build in use is not main HEAD and either predates or postdates the gate. My original report inherited a "desktop 0.5.3" version claim from an earlier draft; I did not independently verify the gate exists in that release, so please treat the version line as unverified.

The code-reading part of the report stands as a description of main: the permissive path (getMentionableAgentPubkeys / shouldHideAgentFromMentions) is computed and then bypassed for any non-locally-managed agent identity. Whether that is currently biting users in a released build, I can no longer assert. Happy for this to be closed as not-reproducible if maintainers read it that way.

[ashtonlance]

Hitting this on a self-hosted fleet — six buzz-acp agents on their own VM, all channel members, none managed by the desktop install. Every one is unmentionable from Buzz Desktop, and the failure is completely silent, so it took a while to land on this issue.

Some field data that may help whoever picks it up.

The symptom is worse than a missing autocomplete entry. Mention resolution happens client-side before signing (the relay can't add tags to a signed event), so when the agent is filtered out of the candidate list there is no p tag on the outgoing message. The relay accepts it, stores it, threads it correctly — and with --subscribe mentions the harness never receives it. Nothing errors anywhere. From the user's side it looks exactly like the agent is ignoring them; from the agent's side nothing happened at all.

We confirmed the mechanism by comparing what's actually stored:

# typed in Buzz Desktop
{"content":"@Rig what up?",     "tags":[["h","<channel>"]]}                       -> never delivered

# same text, same channel, via the CLI
{"content":"@Rig ping",         "tags":[["h","<channel>"],["p","364c0921…"]]}     -> delivered

It regressed for us on a host migration, which may be a useful repro. The agents previously ran on a box where the desktop had local records for them and mentions worked. Moving the same identities to a different host — same pubkeys, same channels, same respond_to — silently broke every mention, because list_managed_agents reads local disk records and those records no longer covered them. Nothing about the relay state changed. So the trigger isn't only "a teammate's agent"; it's also "your own agent, hosted anywhere you aren't running the desktop", which we suspect is common for long-running agents.

Archived predecessors keep resolving. Tangentially related, and it compounded the confusion: after re-keying three agents, users get --name <X> returned both the live identity and its archived predecessor. The lookup consults neither archived_identities nor users.deactivated_at — we verified by setting each in turn and observing no change — so a retired identity stays mentionable forever, and a client picking the wrong candidate p-tags a dead pubkey. Renaming the live agent was the only fix available to us, since the retired one's key was gone and kind:0 is replaceable only by its author.

The proposed reordering in this issue — eligibility before ownership — would fix our case entirely. Happy to test a build against a real multi-host fleet if that's useful.

[jordanurbs]

Any update to this because we are also experiencing the same issue and it's... extremely frustrating.