Desktop @-mention autocomplete only shows locally managed agents

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

User A owns agent X; agent X is a member of a shared channel; respond_to is allowlist (includes User B) or anyone.
User B opens that channel on their own Desktop (does not manage agent X).
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.

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.

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.

test(desktop): assert alice sorts before personas in mention autocomp…

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.

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.

Independent confirmation from another production deployment, plus evidence that may help triage the six open PRs attacking this bug.

Setup

Buzz Desktop 0.5.x on Windows 11 + the stock relay Docker image (self-hosted).
User A owns an agent configured respond_to: allowlist with User B on the allowlist; the agent and both users are members of the same channel.
User B's @ autocomplete never offers the agent (typing the exact display name included). Symmetrically, User A cannot see an allowlisted agent owned by a third user.
Enforcement is fine: buzz messages send --mention <agent-pubkey> from User B wakes the agent and it responds. The failure is purely the client-side candidate gate described in this issue.

Evidence relevant to choosing a fix: the kind:10100 directory is empty in real deployments

An authenticated query against our relay for [{"kinds":[10100]}] returns zero events (checked again today). That's consistent with the source at 8342dfc:

Desktop only ever reads kind:10100 (desktop/src-tauri/src/commands/agent_discovery.rs queries it; nothing in desktop/ publishes it). Saving an agent or editing its respond_to/allowlist publishes nothing to the relay — grants live only in the owner's local managed-agents store (Multi-device: mention picker cannot reach remotely-hosted agents (owner-only unhandled, directory never updated, replies never p-tag authors) #4535 covers this gap).
The only in-tree writer is buzz channels set-add-policy (crates/buzz-cli/src/commands/channels.rs:1004), and it publishes a record containing only channel_add_policy — no respond_to/respond_to_allowlist (and per set-add-policy replaces the full kind:10100 record, hiding the agent from mention autocomplete #3663 it clobbers any fuller record).

So on any deployment where nobody has run set-add-policy, relayAgentsQuery.data is empty, which means mentionableAgentPubkeys contains only locally managed agents and directoryAgentPubkeys is empty.

What that implies for the open PRs

Of the PRs currently open against this bug family, the ones that admit candidates via the mentionable/directory set — #4603, #4137, #4058 — are no-ops on deployments like ours: the set they consult can never contain a foreign agent until something starts publishing respond_to data to the directory. (#4137 even pins the member branch of shouldHideAgentFromMentions as unreachable, which entrenches the dead code this issue is about.)

The PRs that instead pass channel-member agents through to shouldHideAgentFromMentions — #3816, #4047, #4714 — fix the bug today, because its existing member branch ("member + not in directory ⇒ unknown invocability ⇒ show") is exactly the state real deployments are in. Of those, #3816 looks the most careful: its directory-readiness guard avoids offering an agent whose directory entry excludes the viewer during the window where the query is still in flight, while an empty-or-errored directory still degrades to show.

Related: #3125, #3671, #3204, #4489, #4548, and #2603 (same gate also blocks add-member search).

fix(desktop): let channel-member agents reach the mention picker

Another trigger for the same gate: an agent's own owner cannot mention it, if the agent was not created by that Desktop install

Confirmed on Buzz Desktop 0.5.19 against a self-hosted relay. Every repro in this thread so far is cross-owner — user B cannot mention user A's agent. Ours is not. The viewer is the owner, and the agents are still missing from @ autocomplete.

Setup

Three agents provisioned entirely from the CLI — keypair generated locally, NIP-OA owner auth tag signed by the human identity, kind:0 profile published, added to a shared channel by that same owner via buzz channels add-member. No Buzz Desktop create-agent form was involved at any point. Harness runs with subscribe=mentions, respond_to=allowlist including the viewer.

Observed


Channel membership	all three present, `role: member`
Profiles	`display_name` resolves via `buzz users get`
Presence	`online`
Owner	harness logs `owner resolved from BUZZ_AUTH_TAG` = the viewer's own pubkey
Desktop `@` autocomplete	none of the three ever offered, before or after a full app restart
`buzz messages send --mention <pubkey>`	delivered; harness logs `agent_claimed` then `dispatch_pending dispatched=1`, agent replies in-channel within ~15-50s

Why this matters for triage

Per the gate described in this issue, managedAgentPubkeys comes from listManagedAgents, which is scoped to the local install — not to ownership. So the predicate that drops these candidates is not "someone else owns it" but "this Desktop did not create it". Ownership never enters the check.

That makes the blast radius larger than the title suggests: any headless or scripted deployment path is unreachable from the UI for everyone, its own operator included. A team that provisions agents from CI or a deploy script has no @ autocomplete at all, on any machine.

It also constrains the fix. A correct fix has to let channel-member agents reach shouldHideAgentFromMentions regardless of local provenance; keying eligibility off a directory the owner's own client never populated leaves this case broken even when the directory is healthy.

Not tested on 0.5.20. Relay delivery, author gate, and harness dispatch are all healthy here — this is the client-side candidate gate only.

Navigation Menu

Repository navigation

Desktop @-mention autocomplete only shows locally managed agents #3809

Purpose

Blocker

Actual vs expected

Repro

Code

Out of scope for this issue

Fix PR

Topology

Observed

Verified workaround

Setup

Evidence relevant to choosing a fix: the kind:10100 directory is empty in real deployments

What that implies for the open PRs

Setup

Observed

Why this matters for triage

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Desktop @-mention autocomplete only shows locally managed agents #3809

Description

Purpose

Blocker

Actual vs expected

Repro

Code

Out of scope for this issue

Activity

CExKEze commented on Jul 30, 2026

CExKEze commented on Jul 30, 2026

Fix PR

davefmurray commented on Jul 31, 2026

Topology

Observed

Verified workaround

CryptoJones commented on Jul 31, 2026

oceanseth commented on Aug 5, 2026

Setup

Evidence relevant to choosing a fix: the kind:10100 directory is empty in real deployments

What that implies for the open PRs

Eight8Kane commented on Aug 27, 2026

Setup

Observed

Why this matters for triage

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions