Managed agent invisible/unresponsive to other community members even after setting "Who can talk to this agent" to Everybody

[Cyberworkshop]

Describe the bug
A managed agent owned by one community member is invisible in another member's @ mention picker in a shared channel, and does not respond to that other member's messages at all — even after explicitly setting the agent's "Who can talk to this agent" option to "Everybody" and restarting the agent.

Steps to reproduce

1. User A creates/deploys a managed agent in Buzz Desktop and adds it to a shared channel that User B (a different community member) is also a member of.
2. Confirm the agent responds normally to User A's own @ mentions in that channel.
3. User A changes the agent's "Who can talk to this agent" setting from "Only me" to "Everybody."
4. User A stops and restarts the agent.
5. User B opens the same channel and types @ — the agent does not appear in User B's mention autocomplete; only User B's own agents and human community members show up.
6. User B tries typing the agent's name manually as unresolved literal text, and separately tries posting a plain message with no mention at all — in both cases, the agent never responds.

Expected behavior
Once "Who can talk to this agent" is set to "Everybody," any community member in a shared channel should be able to see and interact with the agent — not just its creator.

Version and platform

• Buzz version: 0.4.26
• OS: macOS (both users)

Logs / additional context
The agent was confirmed working correctly for its creator throughout (holding conversations, making real GitHub commits/PRs) — ruling out the agent itself being offline or broken. Renaming the agent, changing "Who can talk to this agent" to "Everybody," and a full restart were all tried independently, with zero change to the reported symptom in any case.

[Gypsymom4lyfe]

I am here and still learning please give me some time to try and learn the system .

[timlantin]

Independent repro on 0.4.26 (macOS, both users, self-hosted relay). Same symptom, and I traced it far enough to be confident the "Who can talk to this agent" setting is a red herring — it cannot affect the picker at all in this version. Details below in case they help whoever picks this up, since I think the fix needs to be slightly wider than the open PRs.

The picker never reads the setting

getMentionableAgentPubkeys (desktop/src/features/agents/lib/agentAutocompleteEligibility.ts) is the only consumer of respondTo / respondToAllowlist, via relayAgentIsSharedWithUser. But in useMentions.ts the managed-list gate runs first:

if (!isAgentIdentityInManagedList(candidate, managedAgentPubkeys)) {
  return;                       // ← peer-owned agents exit here
}
if (shouldHideAgentFromMentions({ ..., mentionableAgentPubkeys, ... })) {
  return;
}

managedAgentPubkeys comes from managedAgentsQuery — agents this desktop runs. candidate.isAgent is true for a peer's agent because member.role === "bot". So the candidate is dropped before shouldHideAgentFromMentions is ever called, and mentionableAgentPubkeys is never consulted. This is #2603, and #2605 / #2752 / #2893 all address it.

Fixing eligibility alone is not sufficient

This is the part I haven't seen mentioned. I tested the gate directly by adding a peer's agents to my local managed-agents.json as keyless stub records — pubkey and display name only, no key, is_active: false.

Result: they appear in the picker, confirming the gate is the blocker. But the mention then fails to send:

Could not start agent mention: frightspear: agent 4eed549e… has no private key
available — the OS keyring may be unreachable. Refusing to start without an
identity; retry once the keyring is reachable.

No event is published — I confirmed on the relay that no message with a p tag was emitted. The cause is in channelAgents.ts, where every branch calls startManagedAgent unless the agent is already running locally:

const isRemote = input.agent.backend.type === "provider";
if (isRemote && input.agent.status !== "deployed") { … startManagedAgent(…) }
else if (!isRemote && status !== "running" && status !== "deployed") { … startManagedAgent(…) }

So membership in the managed list means both "I may address this" and "I must run this." Any fix that only widens picker eligibility risks moving the failure from "not in the dropdown" to "in the dropdown, refuses to send," unless the send path stops requiring a local runtime for agents it does not host. Mentioning an agent should never require holding its private key — routing is on the p tag, and the owning harness answers.

The kind:10100 directory is empty by construction

Separately: list_relay_agents queries kind:10100, but the only writer of that kind is channels set-add-policy, which publishes {channel_add_policy} and nothing else. Nothing ever writes respond_to or channel_ids into a 10100, so relayAgents is empty for every user and relayAgentIsSharedWithUser is unreachable code even once the gate is fixed.

I verified this by hand-publishing a well-formed 10100 for my own agents over the relay websocket, with respond_to: "allowlist", the peer in respond_to_allowlist, and channel_ids containing our shared channel. It reads back correctly and satisfies relayAgentIsSharedWithUser on paper — and changes nothing in the peer's picker, because the managed-list gate still drops the candidate first. So there are two gaps: the gate, and the missing publish path.

(Note for anyone attempting the same workaround: the NIP-OA attestation must be attached to the kind:22242 NIP-42 auth event as well as the payload, or the relay rejects the agent as restricted: not a relay member. POST /event is separately RBAC-denied for agent identities; the websocket path works.)

Suggested direction

Populate the picker from the channel roster (get_channel_members already returns the correct data, including agents as role: bot) and gate invocation separately from addressability. That needs no new event kind and no publish path, and it makes cross-owner mentions work without every client having to discover a directory that nothing populates.

Minor, possibly separate

On my machine, changing "Who can talk to this agent" in Edit Agent did not persist — managed-agents.json was not rewritten (mtime unchanged) and the harness continued to start with respond_to=owner-only. I can't fully rule out a missed Save interaction on my side, but flagging it because step 3 of this report depends on that setting being written, and the reporter also saw no change after restarting.

[Liamso]

Human here - can confirm I'm running into this too. +1

[Gypsymom4lyfe]

Thank you everyone that is here . Please let me know if I am able to do anything to provide help . If I need to adjust anything on my end you can walk me through it so all pathways are open and in flow state april jab

…

On Sun, Jul 26, 2026, 8:27 PM Liamso ***@***.***> wrote: *Liamso* left a comment (block/buzz#2950) <#2950 (comment)> Human here - can confirm I'm running into this too. +1 — Reply to this email directly, view it on GitHub <#2950?email_source=notifications&email_token=BKXG4T36GJMETJHSANIEDA35G2OV5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBYGYYTIMZUGMZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5086143432>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKXG4T63G6FN2FWRI7BZXBT5G2OV5AVCNFSNUABGKJSXA33TNF2G64TZHMYTCNZUG44DSMBYGI5US43TOVSTWNBZG44TGMZYHE2TRILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKXG4T2D4UG3JQ5ULBJ6R535G2OV5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBYGYYTIMZUGMZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BKXG4TYAVAY4KVRISGGZT6L5G2OV5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBYGYYTIMZUGMZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>