Shared Mini-hosted agents still not mentionable on 0.5.6 — no autocomplete chip, no p tag, agent never wakes

[cscholly]

Summary

On Buzz Desktop 0.5.6, an agent hosted on another machine (Mac Mini), owned by identity A, with respond_to: anyone and real channel membership, still does not appear as a mention chip for identity B on a different machine.

Without a resolved mention, outbound kind-9 messages carry only the channel h tag — no p tag for the agent’s pubkey — so the agent harness never routes the message and the agent never wakes.

We upgraded both the agent host and the client to 0.5.6 (including fix(desktop): allow shared agent mentions #4913) before retesting. The failure still reproduces.

This looks like the residual half of the cross-owner mention problem: eligibility may allow shared agents, but discovery / candidate admission still fails for standard desktop-managed agents so non-owners never get a chip or a p tag.

Environment

Item	Value
Desktop (agent host)	0.5.6 (Mac Mini, always-on)
Desktop (human client)	0.5.6 (separate Mac)
Relay	Self-hosted (wss://…ts.net), private tailnet
Agent host identity	A (owner of the agents)
Mentioning identity	B (channel member, not agent owner)
Agent	e.g. display name Larry, role bot in shared channel
Agent config	respond_to: anyone (confirmed on disk / harness / kind 30177)
Agent membership	Channel member, role bot

Expected behavior

1. Identity B types @ in a shared stream channel where the agent is a bot member.
2. The agent appears in autocomplete as a highlighted mention chip (same as a local managed agent).
3. Selecting it (or resolving the mention) produces an outbound kind-9 with a p tag for the agent’s pubkey.
4. The agent harness wakes and replies.

Actual behavior

1. Identity B types @.
2. Agent does not appear as a mention pill/chip in the picker.
3. Free-typing @Larry / @larry sends plain text that looks like a mention in the UI timeline but has no p tag for the agent.
4. Agent is completely silent (never starts a turn — not the 👀/💬-then-kind-5 abort path).
5. Identity A (owner on the Mini) can mention the same agent normally; replies work.

Agent self-diagnosis on a silent message (paraphrased from live chat):

Human posted @larry …. That event has no p tag for my pubkey — only the channel h tag. Without a resolved p mention, the harness does not route the message into my session.

When a later message did carry a proper p tag, the agent woke immediately.

Reproduction steps

1. Machine A (always-on): create/run a managed agent (respond_to: anyone), add it as a bot member of a shared channel.
2. Machine B: join the same community/relay and channel as a normal human member (does not manage the agent locally).
3. From B, open the channel composer and type @.
4. Observe: agent name is absent from autocomplete (no chip).
5. From B, send a message containing free-typed @AgentName are you there? without selecting from the picker.
6. On the relay, inspect the kind-9 tags (or have the agent report whether it received a mention).
7. Confirm: no p tag for the agent pubkey; agent does not wake.
8. From A (owner), @AgentName via autocomplete → agent replies.

Relay verification (optional but decisive)

select left(replace(content, E'\n', ' '), 60) || '  p->' ||
       coalesce((
         select string_agg(substring(t->>1 for 8), ',')
         from jsonb_array_elements(tags) t where t->>0 = 'p'
       ), 'NONE')
from events
where kind = 9
order by created_at desc
limit 15;

• Silent “@Agent” from B → p->NONE (or no agent pubkey).
• Working mention from A → p-><agent pubkey prefix>.

Impact

Breaks the “always-on shared team agents on a Mini” model:

• Teammates can see agent messages but cannot command them via @mention.
• Free-typed @Name looks like a mention in the UI but is not deliverable to the harness.
• Multi-human → Mini-agent workflows fail silently (no error in the app).

Why we believe 0.5.6 did not fully fix this

0.5.6 ships #4913 (https://github.com/block/buzz/pull/4913) (allow shared agent mentions), which admits relay-discovered agents when policy allows the viewer.

This matches the open analysis in:

• #3776 (https://github.com/block/buzz/issues/3776) — cross-owner mentions + eligibility reading a kind nothing publishes
• #4776 (https://github.com/block/buzz/issues/4776) — desktop drops agents it doesn’t manage locally
• #4716 (https://github.com/block/buzz/pull/4716) — open PR to source discovery from kind 30177 (not merged as of this report)

If #4913 was meant to fully close this for desktop-managed shared agents, please treat this as a regression / incomplete fix on 0.5.6. If #4913 only covers a subset (e.g. agents that already publish 10100), please document that and keep the 30177 discovery gap as a blocker for team Mini hosts.

What is not the issue (ruled out)

┌──────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────────┐
│ Check                                                    │ Result                                                                             │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Agent offline / not running                              │ ❌ Agent answers owner mentions fine                                               │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Wrong respond_to                                         │ ❌ anyone on instance + harness                                                    │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Agent not in channel                                     │ ❌ Bot member confirmed                                                            │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Case sensitivity alone                                   │ ❌ Matcher is case-insensitive in source; root failure is “no chip / no candidate” │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Harness permission abort (👀 then 💬 then kind-5 delete) │ ❌ This case is no wake at all (missing p)                                         │
├──────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┤
│ Client still on 0.5.5                                    │ ❌ Both host and client on 0.5.6 before retest                                     │
└──────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────┘

Requested fix

1. Non-owner channel members must be able to @-mention a channel bot agent they don’t manage locally when policy allows (respond_to: anyone or allowlist including them).
2. That mention must show as a chip in autocomplete and emit a p tag on send.
3. Prefer sourcing mentionable agents from events the product actually publishes (kind 30177 and/or channel membership + profile), not only kind 10100 if nothing publishes it.
4. Ideally: free-typed @DisplayName (case-insensitive) also resolves when the agent is a channel member and invocable — but autocomplete chip + p tag is the minimum.

Acceptance criteria

• [ ] From identity B on a second machine, @ lists the Mini-hosted agent as a selectable chip in a shared channel.
• [ ] Selecting the chip and sending produces a kind-9 with p = agent pubkey.
• [ ] Agent wakes and replies without requiring the owner to re-@mention.
• [ ] Free-typed @agentname either resolves the same way or the UI clearly shows it was not resolved (no silent plain-text “fake mention”).

Related

• #3776
• #4776
• #4913 (shipped in desktop-v0.5.6)
• #4716 (open discovery fix)
• Release: https://github.com/block/buzz/releases/tag/desktop-v0.5.6

[crispearson]

Still an issue in 0.5.8.

This seems like a prime use case, surprised it doesn't work this way. Because I like how Buzz is built in general, I'm curious if I should adjust my set up. Or I'm missing something entirely.

[lividas-ai]

Adding a fresh hosted-community reproduction with a topology not yet stated as clearly above: two different human identities, two operating systems, and symmetric cross-owner failure.

Topology

• Human A uses Buzz Desktop on macOS and owns/runs Codex-backed agents.
• Human B uses Buzz Desktop on Windows and owns/runs a Claude Code-backed agent.
• Both humans are members of the same hosted-community channel.
• The relay membership query confirms both humans and all three affected agents are members of that channel; the agents have role bot.
• The remote agents are configured with Respond to: Anyone.

Observed

1. The channel Members UI correctly shows the other person's agents to each human, so profile resolution and channel membership have propagated.
2. In the composer, Human A's @ autocomplete offers only A's locally owned/personal agents and does not offer B's channel-member agent.
3. Human B sees the mirror image: only B's locally owned/personal agents, not A's channel-member agents.
4. The failure is therefore bidirectional and follows local ownership, not OS, model provider, runtime, channel membership, or respond_to policy.
5. As a control, the bundled CLI was used to send a kind-9 message with the remote agent's exact pubkey via --mention. The relay accepted the event and the signed event contains the expected p tag. This confirms the identity is addressable when candidate selection is bypassed. Agent response/liveness is intentionally not asserted here because that is a separate harness path.

This strongly matches the residual discovery/candidate-admission problem described in the issue: Desktop appears to populate agent mention suggestions from the current install's personal/managed-agent inventory instead of admitting eligible remote bot members already visible in the channel roster.

Expected

• For both humans, @ autocomplete should include every remote channel-member agent whose effective policy permits that human (anyone, or an applicable allowlist).
• Selecting the agent should emit its pubkey as a p tag.
• Runtime/provider choice (Codex versus Claude Code) and host OS (macOS versus Windows) should not affect mention discovery.

This blocks the core shared-agent workflow: two teammates can see each other's agents in Members but cannot address them from Desktop. Exact relay event IDs, channel UUID, and pubkeys are available privately if maintainers need them. Desktop version numbers are being collected and can be added in a follow-up.

[dfang]

not fixed on macOS buzz desktop 0.5.23