Desktop @-mention autocomplete only shows locally managed agents

[CExKEze]

Purpose

Teams need to @mention shared / org-level agents from their own Buzz Desktop — for example a research agent owned by someone else but configured with respond_to: allowlist or anyone and present in a shared channel.

Today that is impossible through the UI. Non-owners only see agents managed by their own Desktop install. respond_to settings cannot fix it.

Blocker

In Desktop mention autocomplete, agent candidates are filtered by isAgentIdentityInManagedList before the respond_to / shared-channel eligibility logic runs.

managedAgentPubkeys comes from listManagedAgents (local Tauri command for this install). Any channel member with role: "bot" whose pubkey is not in that local set is dropped.

So the allowlist / anyone eligibility code in relayAgentIsSharedWithUser / shouldHideAgentFromMentions is unreachable for cross-owner agents.

Actual vs expected

Actual	@ list shows only agents this Desktop manages. Cross-owner channel bots never appear.
Expected	Agents that are channel members and that the viewer is allowed to invoke (respond_to: anyone + shared channel, or respond_to: allowlist including the viewer) appear in @ autocomplete.

Repro

1. User A owns agent X; agent X is a member of a shared channel; respond_to is allowlist (includes User B) or anyone.
2. User B opens that channel on their own Desktop (does not manage agent X).
3. User B types @ in the composer.

Result: Agent X is missing. User B only sees agents their install manages.

Note: Explicit CLI --mention <pubkey> still delivers (relay accepts it). This is a Desktop autocomplete UI gate, not a relay delivery failure.

Code

• desktop/src/features/messages/lib/useMentions.ts (~244–262) — addCandidate order: managed-list filter before eligibility hide
• desktop/src/features/agents/lib/agentAutocompleteEligibility.ts (isAgentIdentityInManagedList, relayAgentIsSharedWithUser)
• desktop/src/features/agents/hooks.ts (useManagedAgentsQuery → local listManagedAgents)

Out of scope for this issue

Whether the harness author gate wakes the agent after a successful mention. That is a separate path. This issue is only: non-owners cannot select the agent in Desktop @ autocomplete.

[CExKEze]

We're working on a fix for this and will open a PR from a fork, linked back to this issue with Fixes #3809.

Planned approach, so no one duplicates the work:

• Stop isAgentIdentityInManagedList from dropping channel-member / relay-directory agents on the mention path in useMentions.ts, so eligibility is decided by shouldHideAgentFromMentions / relayAgentIsSharedWithUser rather than by local install membership.
• Keep the existing gate semantics unchanged: respond_to: anyone plus a shared channel, or an allowlist containing the viewer.
• Extend agentAutocompleteEligibility.test.mjs to cover a channel bot the viewer does not manage — visible when eligible, still hidden when not.
• Audit the other isAgentIdentityInManagedList callers (MembersSidebar, useClassifiedMembers, useSearchResults, useNewMessageRecipients) so the change doesn't widen surfaces beyond mention autocomplete.

Out of scope for this PR: the harness author gate (whether the agent wakes after a delivered mention), respond_to semantics, and the mobile/web clients. Happy to adjust the approach if maintainers would prefer a different shape before we push.

[CExKEze]

Fix PR

#3816

Tip: 4e032f7d546b5f9f82fe0b4bd2051ddc782fc270 on fix-3809-desktop-cross-owner-mentions (fork CExKEze/buzz).

Desktop @-mention autocomplete now offers eligible cross-owner channel-member agents (managed-list gate no longer drops them before shouldHideAgentFromMentions). Non-member relay-only agents stay hidden.

Buzz coordination: channel 7eeeb66d-80cc-4680-87c6-0d38d8d25624.

[davefmurray]

Confirmed in a real two-Mac setup on Buzz Desktop v0.5.2.

Topology

• One macOS machine hosts a Grok Build managed agent.
• A separate MacBook Air is the human operator/cockpit and does not manage or run that agent.
• The Air user's identity is explicitly present in the agent's respond_to: allowlist.
• The human and agent are members of the same channel, and the agent is online.

Observed

• On the Air, Desktop @ autocomplete never offers the remote agent, including when typing its exact display name.
• The host harness starts cleanly with respond_to=allowlist(1), connects to the relay, subscribes to the shared channel, and publishes online presence.
• A relay lookup returned no kind-10100 agent-directory event for this agent.
• The Air has no local buzz-acp or Grok worker processes.

Verified workaround

I configured the host agent with:

BUZZ_ACP_SUBSCRIBE=config
BUZZ_ACP_CONFIG=/absolute/path/to/grok-builder.toml

and this scoped rule:

[[rules]]
name = "grok-prefix-general"
channels = ["<shared-channel-uuid>"]
kinds = [9]
require_mention = false
filter = 'str_starts_with(content, "?grok")'
prompt_tag = "grok-prefix"

From the Air, a normal kind-9 message with no p tag:

?grok reply exactly READY

was received by the host agent, which replied READY about 12 seconds later. A second test after reducing the host pool to one worker also succeeded.

That confirms the relay path, remote runtime, channel subscription, and author allowlist are healthy; the user-facing failure is isolated to Desktop's cross-owner mention candidate path. This appears to be the exact in-channel bot case targeted by #3816.

All real identities, keys, relay details, channel IDs, and event IDs are intentionally omitted.

[CryptoJones]

Confirmed in a hosted-community deployment with an additional permission case:

• User B was promoted from community member to community admin.
• User B is a member of the affected channels.
• The managed agents are bot members of those channels, online, and their effective instance configuration is respond_to: anyone.
• The host Buzz Desktop and all managed-agent harnesses were cleanly restarted; fresh logs showed all agents reconnecting and setting presence online.
• User B refreshed/restarted their client.

User B still cannot resolve/tag those agents from @ autocomplete. Promoting the remote user to community admin does not bypass the local-managed-agent eligibility gate. This further isolates the problem from relay role, channel membership, runtime liveness, and the harness author gate: it is the cross-client autocomplete/discovery behavior described in this issue.

A newly created managed agent showed the same behavior after being added as a bot to every shared channel.