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

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

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.
Confirm the agent responds normally to User A's own @ mentions in that channel.
User A changes the agent's "Who can talk to this agent" setting from "Only me" to "Everybody."
User A stops and restarts the agent.
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.
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.

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

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.

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

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: ***@***.***>

Another independent repro, with wire-level evidence for the point raised above: widening the picker is not sufficient — the receive side also ignores non-owner mentions even when the p tag is delivered.

Setup: community relay superbuilders.communities.buzz.xyz, shared channel with two humans (A = agent owner, B = another member) plus A's managed agent. A set the agent's "Who can talk to this agent" to Anyone. B's picker does not offer the agent (same symptom as this report), so we bypassed the composer entirely and published the mention events from the CLI with a correct p tag for the agent's pubkey.

Observed (all times UTC, 2026-07-27, from relay data):

Two p-tagged mentions from the non-owner, at 22:40:00 and 22:54:19. Both accepted by the relay and readable back with the p tag intact — delivery confirmed on the wire. Both ignored (no pickup after 21+ min and 7+ min respectively).
In the same window, the agent picked up its owner's mention (sent 22:34:59) in 128 s and delivered the resulting task at 22:49:21.
The agent was online throughout (presence refreshed 23:00:44) and idle after 22:49.

So even a perfectly formed mention event only rouses the agent when it comes from the owner. One caveat: from outside we can't distinguish "the harness filters triggering events by owner pubkey" from "the Anyone setting never persisted to the harness config" — the latter would corroborate the non-persistence observation in the comment above. Either way the setting's observable contract is broken end to end, and the open picker PRs (#2605 / #2752 / #2893 / #3108) fix a necessary but not sufficient half of this issue.

@spencer-owens

Another community confirmation, managed relay; Buzz Desktop 0.4.26 / macOS on the owner side), plus a DM-channel wrinkle that adds a second, distinct receive-side gate to the one @spencer-owens documented above.

Repro matching this report

Owner A runs several desktop-managed buzz-acp agents. Member B (different member, separate machine) cannot @-resolve any of A's agents from the composer, and confirmed it directly ("No te puedo arrobar" — "I can't @ you", 2026-07-27 20:27 UTC). One of A's agents has had respond_to: "anyone" in the desktop's managed-agents.json since its creation at 15:51 UTC that day; hours later other members still couldn't mention A's agents. Consistent with @timlantin's analysis that the picker never consults the policy (#3125 / #2603): the setting changes nothing observable.

DM channels: the `p` tag is NOT the missing piece there — `require_mention` is

In a 1:1 DM channel between B and A's agent, B's desktop does p-tag the agent even though @ never resolves in the composer:

c12775e7…490d (2026-07-27 20:23:43 UTC) — plain text, no literal @ anywhere in content, correct ["p", <agent pubkey>] tag present.
8d4cf5a8…8d42 (20:27:05 UTC) — same shape.

Both were accepted by the relay and were readable from the agent's own session (the agent surfaced them via buzz feed get and answered in-thread), so relay-side delivery and agent-side visibility were intact. The agent's buzz-acp harness never woke on either — they were dropped by the require_mention literal-@ filter, which has no DM exemption (#2860 / #2747).

Two consequences for verifying a fix end-to-end:

Fixing picker eligibility alone still leaves 1:1 DMs dead. In DMs the events already carry a correct p tag today and the agent still doesn't wake; that path dies at require_mention, not at the picker and not at delivery.
There are at least two independent receive-side gates. Our drop has a confirmed different cause than the one observed on superbuilders above: our events contained no literal @, so the mention-text filter fully accounts for it. Whatever ignored spencer-owens' correctly-formed, @-bearing channel mentions is a separate check on top of buzz-acp: agent in a 1:1 DM only wakes on an explicit @mention — plain DM messages are dropped by require_mention #2860.

Happy to re-test on this community once a build with #3110 (or the wider fix per #3125's acceptance criteria) is available.

Confirming this with an independent repro and relay-side evidence (2026-07-30). Same behavior, and the data shows the failure is client-side, before publish.

Setup: managed agent "Checker" owned by me, access set to Anyone; agent is a member of a shared channel that also has a non-owner human member (different community member, own machine).

Observed:

For the non-owner, the agent does not appear in the @-mention autocomplete at all — even after the access change and full app restarts on both sides.
Relay-side: no kind-9 event authored by the non-owner carries the agent's p tag anywhere in the channel history covering the affected window. The same user's mentions of a different agent (one they own) tag and publish fine — so this is specific to other-owned agents, not mentions generally.
Control: as the owner, my own @mentions of the agent resolve, publish with the p tag, and wake the agent within seconds (e.g. events ec447ec06d13...08b8 and 1cc467c86d29...ee45, both answered in <30 s).

So with access = Anyone: owner mentions work end-to-end; for a non-owner the mention can never even be composed. This matches the root-cause analysis in #3125 / #3671 — the local managed-agent-list guard in useMentions.ts filters the agent out before the access-scope/allowlist eligibility check runs, which explains why the "Everybody"/"Anyone" setting is ignored and why restarts don't help (the other user's machine never manages the agent locally).

Happy to provide full event IDs/pubkeys or run further tests on our setup if useful.

@timlantin

Reproduced this end-to-end on my own community relay (buzz.cyberworkshop.co.nz, latest main as of 2026-07-31) with a real non-owner member, and found a second, distinct root cause beyond the picker-eligibility gate already tracked in #2603/#3125/#3671 (and the fix PRs #2605/#2752/#2893/#3108/#3110).

Setup: managed agent ("Bens Fizz") owned by me, in a shared group channel (t=stream, confirmed via the channel's kind:39000, not a DM) that also has a non-owner human member ("Vic," separate machine). Access set to Everybody/Anyone via Edit Agent.

Step 1 — confirmed the picker bug independently. Vic's @ picker never offered the agent, matching every other report here. Bypassed it entirely using buzz-cli's explicit --mention <pubkey> flag (attaches the p tag directly, no local managed-agent-list lookup involved). The event published correctly with the right p tag — relay-side confirmed. So the delivery/publish path is fine once you get past the Desktop picker; this corroborates the fix direction in the open PRs.

Step 2 — even with a correctly p-tagged non-owner mention, the agent still didn't respond. Ruled out both:

DM misclassification / fail-closed-to-DM in author_allowed's is_dm_channel check (buzz-acp/src/lib.rs) — the channel's kind:39000 metadata is well-formed and resolves in single-digit ms, so that path isn't firing here.
Agent being dead/misconfigured — it replied to my own mentions within ~12s throughout.

Root cause found: Edit Agent's "Who can talk to this agent" toggle does not persist to the on-disk config the harness actually loads. managed-agents.json kept "respond_to": "owner-only" for this agent despite the UI showing "Anyone," including after an explicit agent restart. This is the same thing @timlantin flagged as a "Minor, possibly separate" aside — it's not minor, it's the actual blocker in this repro once the picker is bypassed. author_allowed (buzz-acp/src/lib.rs) only checks respond_to; with it stuck at owner-only, every non-owner mention is silently dropped regardless of what the UI displays.

Fix verified live: manually edited respond_to to "anyone" directly in managed-agents.json, let the agent auto-restart (auto_restart_on_config_change: true). Timestamped before/after on the same relay:

Pre-fix: two correctly-tagged non-owner mentions (09:41:55, 09:49:33 UTC) — zero replies.
Post-fix restart (09:51:03 UTC): next non-owner mention (09:53:42 UTC) got a real reply at 09:54:05 UTC (23s), addressed to Vic by name.

Implication for scoping the fix: the picker-eligibility PRs already open (#2605/#2752/#2893/#3108/#3110) fix finding the agent, but even once merged, non-owner interactions will still silently fail for any agent where this setting never wrote through — which, per @timlantin's independent report and this repro, may be most/all agents set to Anyone/Allowlist via Edit Agent after creation rather than at initial setup. Worth tracking the settings-persistence bug (Edit Agent → managed-agents.json's respond_to/respond_to_allowlist fields) as a first-class blocker alongside the picker fix, not a side note — fixing the picker alone will just move the failure from "invisible in the dropdown" to "visible, addressed correctly, still silently ignored."

@tlongwell-block

@tlongwell-block @wpfleger96 — not trying to push, just checking direction. There's a fair amount of community work converging on cross-owner agent mentions (picker eligibility, DM require_mention exemption, respond_to persistence) — a few of us have PRs open in this area (ours: #3443, #3448, #3456).

Is enabling mentions of another member's agent aligned with where you want this to go, or is it intentionally held back for now (e.g. still settling the trust/ownership model)? Genuinely just informational — want to keep contributing in the right direction instead of duplicating effort. Happy to help consolidate around whatever approach you'd prefer.

same, Agent not triggered by non-owner mentions after changing agent visibility/access

Still reproducible on Desktop 0.5.23 (macOS, Darwin 25.3.0), on a self-hosted community relay. Adding one detail that I did not see spelled out above: there is no UI path at all that produces a p tag for the agent — the failure happens at addressing time, before any respond_to / access check can even be reached.

Setup. Owner aefe0c0e… runs a locally managed agent 4d9e9531… (Claude harness via buzz-acp) in a shared channel. Non-owner member 5d59e7a4… is in the same channel, on their own machine.

Relay-side state is correct. The agent is a channel member with the bot role, and its kind:0 profile is published:

$ buzz channels members --channel <channel>
[{"pubkey":"aefe0c0e…","role":"owner"},
 {"pubkey":"4d9e9531…","role":"bot"},
 {"pubkey":"5d59e7a4…","role":"member"}]

$ buzz users get --pubkey 4d9e9531…
[{"display_name":"Peggy","pubkey":"4d9e9531…"}]

Observed. The non-owner's @ picker never lists the agent, and every message they send carries no p tag, so the harness is never woken. Raw tags pulled from the relay:

time (UTC)	author	content as typed	tags
08:05	non-owner	`#peggy tu es la ?`	`h` only
08:14	non-owner	`@Peggy`	`h` only
09:38	non-owner	npub inside a fenced code block	`h` only
08:10	owner	`@Peggy …` (picker-resolved)	`h`, `p 4d9e9531…`

New bit — the documented workaround does not work either. #6430 notes that mentioning a hidden agent "still works if the pubkey is supplied some other way (CLI / paste)". Pasting the npub into the Desktop composer does not produce a mention, even for the owner:

time (UTC)	content as typed	tags
09:43	`@nostr:npub1fk0f2v2…`	`h` only
09:45	`@nostr:npub1fk0f2v2…` (unformatted)	`h` only

The npub decodes to 4d9e9531571ad323404670f334680a64b5270410586943db0d5f1e13d5b5cda6, i.e. exactly the agent that is a bot member of that channel. So an explicit, unambiguous, correctly-spelled identity pasted into the composer is silently dropped instead of being resolved into a p tag. Sending through the buzz CLI with --mention <hex> works fine against the same relay, which isolates this to the Desktop composer.

Caveat, for honesty. In our install the agent is currently "respond_to": "owner-only" (managed-agents.json), so this comment is not an independent confirmation of the "set to Everybody and it still fails" part of the original report. It confirms the layer underneath it: with the picker hiding the agent and npub paste not resolving, a non-owner has no way to emit a mention at all, whatever the access setting is. Happy to re-test the Everybody path and report back.

Impact for us. A team cannot share the agents one member hosts: colleagues see them in the channel member list, can read what they post, and cannot address them. Related: #4489 (useMentions.ts:249 / isAgentIdentityInManagedList), #6430, #4548, #7222 for the remote-host variant.

Buzz version: 0.5.23 · OS: macOS (Darwin 25.3.0)

Navigation Menu

Repository navigation

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

The picker never reads the setting

Fixing eligibility alone is not sufficient

The kind:10100 directory is empty by construction

Suggested direction

Minor, possibly separate

Repro matching this report

DM channels: the `p` tag is NOT the missing piece there — `require_mention` is

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Gypsymom4lyfe commented on Jul 26, 2026

timlantin commented on Jul 26, 2026

The picker never reads the setting

Fixing eligibility alone is not sufficient

The kind:10100 directory is empty by construction

Suggested direction

Minor, possibly separate

Liamso commented on Jul 27, 2026

Gypsymom4lyfe commented on Jul 27, 2026

spencer-owens commented on Jul 27, 2026

surfingdev commented on Jul 28, 2026

Repro matching this report

DM channels: the p tag is NOT the missing piece there — require_mention is

nik-maniya commented on Jul 30, 2026

Cyberworkshop commented on Jul 31, 2026

surfingdev commented on Aug 2, 2026

malatech commented on Aug 3, 2026

JSL401 commented on Sep 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

DM channels: the `p` tag is NOT the missing piece there — `require_mention` is