Desktop hides allowlisted agents owned by another user from @mention autocomplete

[pax-k]

Summary

The desktop composer prevents a user from mentioning an agent owned by someone else even when the agent is present in the channel and its respond_to policy explicitly permits that user.

Observed in wss://formidable.communities.buzz.xyz:

• Testbot is owned by gabimoncha.
• Testbot is a bot member of #general.
• Testbot is configured so Pax may invoke it.
• Gabimoncha can resolve and mention Testbot.
• Pax's @Testbot remains plain text and the published event has no Testbot p tag, so ACP is never woken.

Root cause

PR #2149 made the current user's local managed-agent list authoritative for every concrete agent identity in mention autocomplete.

useMentions.ts calls isAgentIdentityInManagedList(candidate, managedAgentPubkeys) before the existing respond_to/allowlist/shared-channel eligibility check. An other-owned agent is therefore discarded even when getMentionableAgentPubkeys() has correctly classified it as invocable for the current user.

This conflates two different concepts:

• managed by me — ownership/lifecycle control
• invocable by me — owner-only, allowlist, or anyone response policy

Expected behavior

A concrete agent should be mentionable when either:

• it is locally managed by the current user, or
• its relay profile and channel relationship authorize the current user through respond_to.

Agents that are neither locally managed nor invocable must remain hidden.

Acceptance criteria

• An allowlisted user can select an other-owned agent from desktop @mention autocomplete.
• An anyone agent shared through a joined channel can be selected by other members.
• The sent event contains the selected agent's p tag.
• Owner-only and non-allowlisted other-owned agents remain hidden.
• Locally managed agents remain visible regardless of response policy.
• Focused unit and desktop E2E coverage protects the owner/allowlist distinction.

Suspected files

• desktop/src/features/messages/lib/useMentions.ts
• desktop/src/features/agents/lib/agentAutocompleteEligibility.ts
• desktop/src/features/agents/lib/agentAutocompleteEligibility.test.mjs
• desktop/tests/e2e/mentions.spec.ts

Regression introduced by #2149.

[spencer-owens]

Independent confirmation of the anyone acceptance criterion, from a different community (superbuilders.communities.buzz.xyz): an agent whose owner set "Who can talk to this agent" to Anyone, joined to a shared channel, never appears in another member's autocomplete — the picker offers only the viewer's own agents plus humans. Cross-checking relay data for the channel's last 200 events, successful p-tagged agent mentions line up 1:1 with agent ownership (via auth tag): no non-owner has ever produced a p-tagged event for another user's agent through the composer.

One heads-up for verifying the fix end to end: in our repro, hand-publishing a correctly p-tagged mention via CLI (bypassing the composer) still did not rouse the target agent, while owner mentions worked in the same window — details in #2950. Picker eligibility and receive-side filtering may need to land together for the acceptance criteria here to be observable in practice.

[vesc-baek]

Independent confirmation (self-hosted community) — 2026-07-30

Setup: self-hosted Buzz community/relay (URL redacted on request of the operator)
Channel: shared channel with bot-role agents + second human member
Desktop: Buzz Desktop does not offer another user's managed bots in @ autocomplete for a second human who is a channel member and is on the agent respond_to allowlist.
Mobile (same account/community): @ shows the managed agents; selecting them attaches a real agent p tag and ACP wakes.
CLI bypass: buzz messages send --mention <agent-pubkey> wakes the agent.

Channel membership (CLI)

Bot-role members present include the always-on host's hermes and Fizz (plus other bots). Second human is a normal member / owner of the channel depending on channel.

Why this is blocking

This is the always-on shared-agent host pattern (one Mac mini runs warehouse agents; other humans invoke them). Desktop makes the agents look dead; Mobile works. Feedback already filed via Desktop Send Feedback from the affected user.

Related open fix

#3609 looks correctly aimed at the #2149 managed-list gate before invocability. Happy to retest on our relay the moment a build/release includes it.

Please prioritize merge/review of a #3125 fix path — maintainer direction is the remaining blocker more than missing patches.

---

Note: earlier revision of this comment included a concrete community hostname; removed as unnecessary for triage.

[vesc-baek]

Maintainer pick-one request (2026-07-30) — field pressure

Cross-owned / shared always-on agents still cannot be @'d from Desktop for non-owner humans on a self-hosted community (hostname intentionally not public). Mobile works; CLI --mention works. This is blocking multi-user warehouse-agent hosting.

Open fix PRs that all attack the same managed-list gate (please pick one and merge)

PR	Notes
#3609	isAgentIdentityInManagedList + invocable set; CI green earlier; 0 reviews, mergeStateStatus=BLOCKED / REVIEW_REQUIRED — our preferred narrow fix for #3125
#3110	let mentionable relay agents through managed-list gate
#3292	Desktop drops every relay-directory agent before eligibility
#3387	include relay agents in picker results
#3672	channel-member agents without local managed list
#3108	channel-member agents into @ picker
#2893	channel-member agents across owners
#2333	shared agent mentions
#2693	draft: allow channel member agents in mentions

main still runs managed-list gate before shouldHideAgentFromMentions in useMentions.ts (~L249), so getMentionableAgentPubkeys / invocability never saves cross-owned bots.

Ask

1. Assign a maintainer to choose one PR shape today (or close-as-duplicate the rest against the winner).
2. Target a Desktop release note so field users on 0.5.2 know when to upgrade.
3. We will retest on our community within an hour of a build that includes the winner.

Related field comments: earlier on this issue and on #3609 from @vesc-baek today.

---

Note: concrete community/relay hostname removed from this comment; not required for maintainer action.