Cross-desktop @mention autocomplete doesn't discover managed agents from other Desktop instances

[anindyar]

Bug Description

When a managed agent is created on one Buzz Desktop instance (Machine A), it is not discoverable in the @mention autocomplete picker on a second Buzz Desktop instance (Machine B) connected to the same relay.

Steps to Reproduce

1. On Machine A, create a managed agent via Buzz Desktop UI using the Claude Code (native) runtime
2. The agent starts, connects to the relay, and responds to mentions from Machine A's Buzz Desktop
3. On Machine B, open a channel where the agent is a member
4. Type @ to open the mention autocomplete picker
5. The agent from Machine A does not appear in the picker

Expected Behavior

Agents managed by other Desktop instances should appear in the @mention autocomplete picker when they are channel members and have valid profiles on the relay.

Actual Behavior

Only locally-managed agents appear in the autocomplete picker. Relay-discovered agents (from list_relay_agents / kind:10100 events) are not showing despite:

• Being channel members with role: "bot"
• Having valid kind:0 profiles
• Having kind:10100 agent profile events published (via buzz-acp connection)

Key Observation

An agent created via the standalone buzz-acp binary (ACP harness, e.g., Goose) IS visible in the cross-desktop autocomplete. Only agents created via Buzz Desktop's native managed agent system with Claude Code harness are NOT visible.

This suggests the native Claude Code managed agent runtime publishes different Nostr events than the ACP harness, or doesn't publish kind:10100 events at all.

Workaround

Mentions work when sent from the same Desktop that manages the agent, or via the buzz CLI with explicit --mention <pubkey>. The agents respond correctly — only the autocomplete picker is affected.

Environment

• Two Buzz Desktop instances (v0.5.3) on separate machines, connected to the same self-hosted relay
• Both Desktop instances authenticate and see the same channel data
• Closed relay (BUZZ_REQUIRE_RELAY_MEMBERSHIP=true)

Diagnostic Details

• buzz channels members confirms all agents are channel members with role: "bot"
• buzz users get --pubkey <agent> returns valid profiles for all agents
• buzz users presence --pubkeys <agent> shows agents as "status":"online"
• buzz-acp was run with each agent's private key for ~10 seconds to publish kind:10100 events
• Buzz Desktop on Machine B was restarted after kind:10100 publication — picker still doesn't show the agents

[MaxWynnDev]

Hitting this on Desktop 0.5.4 (Windows). Adding evidence, because we spent a while assuming it was our misconfiguration and it isn't.

Setup: one managed agent registered on Desktop instance A (the owner's machine), running against a self-hosted relay. Two other members on their own Desktop instances, same community, same channel.

Symptom: the owner can @-mention the agent and it responds normally. On the other two Desktops, a bare @ lists no agents at all — not the agent under a wrong name, not a duplicate, nothing. Typing the name by hand leaves it as presentation-only text, so the event carries no mention_pubkeys, and with the agent on subscribe=mentions it never receives the message. From the users' side it looks like the agent is ignoring them.

Ruled out, all verified rather than assumed:

• The agent has a published profile on the relay. buzz users get --name <name> returns it with display_name and picture, so name resolution works at the relay level.
• The agent is in the channel's memberPubkeys, and the channel reports the correct memberCount.
• respond_to=anyone.
• The agent process is healthy: connected, discovered N channel(s), subscribed to the channel in question, presence set to online.
• Not a name collision. We did have a stale archived identity sharing the display name, and banning it changed nothing (side note: users get --name still returns identities that are both archived and banned, which may be worth its own issue).
• Flipping the agentManagedProfiles client feature override and restarting had no effect.

The distinguishing factor really does appear to be that the owner's client resolves the agent from its own local managed-agents state, and no other client has any path to discover it.

On the linked PR: #4309 looks like the right idea (resolving hand-typed mentions at send time), but it only touches mobile/lib/features/channels/compose_bar*, so it doesn't address this issue, which is Desktop-specific.

One workaround that does not work, in case it saves someone else the attempt: setting BUZZ_ACP_SUBSCRIBE=all plus BUZZ_ACP_NO_MENTION_FILTER=true does make the agent receive non-mention traffic, so delivery opens up. But the agent then thrashes. The log shows repeated non-cancelling steer ack received on one channel, each extending in-flight deadline, the hard deadline renewing to ~5s, then:

WARN buzz_acp::acp: hard turn timeout exceeded (silence 5.01s)
WARN buzz_acp: agent_returned — respawning (cancel-drain timeout) outcome="cancel_drain_timeout"

followed by the instance stopping. So under subscribe=all a busy channel appears to starve the in-flight turn indefinitely. Might be worth a separate issue.

Also worth flagging: BUZZ_ACP_NO_MENTION_FILTER=1 makes every agent fail to spawn with error: invalid value '1' for '--no-mention-filter' and the whole fleet stays down. true works. Not a bug, but an easy way to take all your agents offline.

Happy to test a Desktop-side fix against this setup if that's useful.