[Bug] Remote managed agents are hidden and unmentionable on secondary devices

[geff08565-sketch]

Summary

A cloud-connected managed agent that runs on Mac A is not visible or mentionable from Buzz Desktop on Mac B, even when both desktops use the same community/account and the agent is already a member of the channel.

The agent is visible and mentionable on Mac A. On Mac B, direct messages to the agent work, but the agent is absent from the channel member/mention UI.

This appears to couple two separate concepts:

1. discovering/mentioning a remote cloud agent; and
2. owning and launching that agent's local runtime.

Environment

• Buzz Desktop 0.4.21
• macOS on both machines
• Same hosted Buzz community and same human identity/account
• Agent runtime (buzz-acp with an OpenClaw ACP adapter) runs only on Mac A
• Agent is connected to the hosted relay, online, and subscribed to the channel

Steps to reproduce

1. On Mac A, create/configure a managed ACP agent and connect it to a hosted Buzz community.
2. Add the agent to a channel as a bot member.
3. Confirm on Mac A that the agent appears in the channel and responds to @mentions.
4. On Mac B, sign in to the same hosted community with the same human identity/account.
5. Open the same channel and type @.

Actual behavior

• Mac B does not show the remote agent in the mention/member UI.
• Other agents present in Mac B's local managed-agents.json are shown (including agents marked "not in channel").
• The missing remote agent is nevertheless reachable by direct message from Mac B.
• Relay/channel membership is correct, and the remote runtime on Mac A is online.
• Restarting Buzz Desktop on Mac B does not fix the problem.

As a diagnostic experiment, adding a keyless/inactive record for the remote agent's public key to Mac B's local managed-agents.json makes the agent appear in @ autocomplete. However, mentioning it then makes Buzz attempt to start the agent locally on Mac B and produces a warning that the OS keyring may be unreachable. Mac B does not possess the agent's private key by design.

This diagnostic record was not intended as a supported workaround; it demonstrates that mention visibility is gated by local managed-agent ownership and that mention dispatch then invokes the local lifecycle path.

Expected behavior

• Any agent that is a member of the current hosted channel should be visible and mentionable from every signed-in client authorized to view that channel.
• Only the machine that owns the agent's private key/runtime configuration should be able to start, stop, or reconfigure the runtime.
• Mentioning an online remote agent should send the mention to its existing remote runtime; it should not require a local managed-agents.json record or local keyring entry.

In short: remote visibility/invocation should be separate from local runtime ownership.

Impact

This breaks the primary multi-device workflow: a user cannot reliably communicate with agents running on an always-on Mac mini from another Mac, despite using the same hosted community and despite the agents being online and channel members.

It also creates a dangerous UX ambiguity: attempting to restore visibility with a local definition causes the second client to try to launch a duplicate runtime and ask for keyring access.

Suggested direction

• Build mention candidates from hosted channel membership/profile data, not only local managed-agent definitions.
• Represent remote agents as non-owned/non-launchable entities on secondary clients.
• Route mentions to the hosted agent identity without calling the local managed-agent start path.
• Keep lifecycle controls gated on possession of the local private key/runtime definition.

Related issues

• Agent @mentions silently fail when mentioned agent is offline #1743 covers mentions to offline agents, but not cross-device discovery of an online remote agent.
• desktop: replace hard boot abort with a keyring-locked screen when keyring is unreachable post-migration #1609 covers unavailable keyring UX, but not the incorrect local-launch attempt for a remote agent.
• Additional Running Agents after restart #2157 discusses duplicated/local agent definitions, but not hosted-agent visibility across devices.

[ScaleLeanChris]

I reproduced the same lifecycle/discovery coupling with an external Hermes gateway on Buzz Desktop 0.4.22.

The identity is an owner-attested Buzz agent key, but Hermes owns the runtime and connects directly to the relay. I initially used a Claude Code managed-agent record only to provision the identity. While that local record existed, mentioning the identity could launch Buzz's local ACP harness and race the external Hermes gateway, producing a duplicate reply. Removing the local managed-agent record fixed the duplicate: the external gateway now authenticates with NIP-42 + NIP-OA over WebSocket, receives the mention, and posts exactly one threaded reply.

Two UI artifacts remain after the local record is removed:

• The Agents page still shows the built-in Hermes / Start Hermes persona card. That button starts a local Buzz ACP persona; it does not report or control the external Hermes runtime.
• The external Hermes profile remains discoverable from relay identity/profile data, but its historical ACP observer activity can look like current managed-runtime state.

This supports the issue's proposed separation: relay identity and mentionability should come from hosted membership/profile state, while Start/Stop controls should appear only when the client owns that runtime. An explicit external or remote-managed runtime type would also give gateways a truthful status surface without registering a local harness.

Related Hermes integration issue: NousResearch/hermes-agent#68871

[hbendev]

#2314 fixes this (and #2149 introduced it)

I support this, I think it makes sense to allow mentioning a bot when the member access is configured to Anyone or Allowlist. Would open up using Buzz from environments without an ACP running (web, mobile). Use case: sharing the relay with non-technical people, and you, as a relay owner, want to pay for the LLM usage (but really, anybody, in the end, it was you who reconfigured the respond-to field and opened up your own agent).

[hbendev]

In fact, this creates a clear Desktop/Mobile inconsistency.

Desktop identifies shared agents through relayAgentIsSharedWithUser: allowlisted users qualify, whereas agents configured to respond to anyone require a shared channel. However, addCandidate rejects non-locally-managed agents before applying those sharing rules.

Mobile has no equivalent restriction. It applies the sharing rules and includes eligible non-member agents. Its comment stating that this mirrors Desktop’s useMentions is therefore no longer accurate.

Is this inconsistency intentional? If not, #2314 appears to restore the shared-agent behavior.

Oh, and also. You can just DM these agents from the remote client just fine, and they'll respond.

[tonic20]

Still live at main HEAD (acfbb1b, v0.4.23) — confirming with a real external-Hermes repro.

Setup: an external Hermes-bridge agent (owner-attested Buzz key) published a valid kind:10100 profile (respond_to: anyone, scoped to a shared channel) and joined that channel as a bot member. It's reachable by DM and by p-tagged mentions, but never appears in Desktop @ autocomplete — exactly as described here.

Root cause (matches @hbendev's read): in desktop/src/features/messages/lib/useMentions.ts, addCandidate runs isAgentIdentityInManagedList(candidate, managedAgentPubkeys) and drops every non-locally-managed agent before shouldHideAgentFromMentions can apply the relay/invocability rules. So the member-eligibility branch of shouldHideAgentFromMentions (and its shows member agents with unknown invocability unit test) is unreachable for any agent you don't personally manage.

On the two open PRs — #2314 vs #2333. I traced both through the actual eligibility functions at HEAD. Both surface the in-channel member bot correctly, but they differ on an existing tested behavior:

QUINN  (relay-only, allowlist incl. viewer, NON-member) — e2e test expects HIDDEN
  current (pre-filter) : HIDDEN
  #2314   (no pre-filter): SHOWN   <-- regresses "relay-only agents stay hidden ... even when allowlisted"
  #2333   (mentionable)  : HIDDEN
OMAR   (member bot, respond_to anyone, shared channel) — want SHOWN
  current : HIDDEN  (the bug)
  #2314   : SHOWN
  #2333   : SHOWN

Why #2314 regresses: deleting the pre-filter outright lets an allowlisted non-member relay agent through, because relayAgentIsSharedWithUser treats an allowlist match as "shared" regardless of channel → it lands in mentionableAgentPubkeys → shown. #2314's pnpm test (3268 pass) is unit-only and doesn't exercise the relay-only agents stay hidden from channel mentions even when allowlisted Playwright spec, so it passed locally.

#2333 avoids this with a narrower gate — isAgentIdentityMentionable = managed || (isMember && role === "bot") — which keeps the allowlisted-non-member agent hidden while admitting in-channel bots, and it ships both a unit test and an e2e test for the shared-in-channel-bot case.

Recommendation: land #2333 (complete fix + regression coverage; currently draft). #2314 would need to adopt the narrower gate before it's safe to merge.