Desktop agent launcher reuses another community's agent identity, causing "restricted: not a relay member" on self-hosted relays

[hideous-strength]

Environment

• Buzz Desktop v0.5.7 (macOS, aarch64)
• Relay v0.2.0 (ghcr.io/block/buzz:main), two self-hosted closed relays via deploy/compose
• Desktop connected to three communities: two self-hosted relays plus one *.communities.buzz.xyz hosted community

Summary

With multiple communities configured, the desktop's managed-agent launcher selects which agent identity (keypair) to launch by agent name, not by (name, community). It repeatedly launched the hosted community's Fizz and Honey keypairs against both self-hosted relays. Closed relays correctly reject the foreign pubkey, so the agents die with:

WARN buzz_acp::relay: initial relay connect failed with terminal error: Auth failed: restricted: not a relay member
Error: relay connect error: Auth failed: restricted: not a relay member

and the UI shows harness exited with status exit status: 1.

Evidence

managed-agents.json correctly holds one entry per (name, relay_url), each with its own pubkey — the registry itself is fine:

Bumble  wss://<self-hosted-A>   pubkey b9566191…
Bumble  wss://<self-hosted-B>   pubkey 34b6d4ac…
Bumble  wss://<hosted>.communities.buzz.xyz  pubkey dbe71ddb…
Fizz    wss://<self-hosted-A>   pubkey d22e491c…
Fizz    wss://<self-hosted-B>   pubkey 960870f6…
Fizz    wss://<hosted>.communities.buzz.xyz  pubkey 64ecfde7…
Honey   … (same pattern)

But the per-agent log files (agents/logs/<agent-pubkey>__<community-id>.log) show the launcher crossing them:

• 64ecfde7…__<community-A-id>.log — the hosted community's Fizz pubkey, connecting to wss://<self-hosted-A> → rejected, "not a relay member"
• 1d4fcaa7…__<community-A-id>.log — the hosted community's Honey pubkey, same rejection
• Later the same two hosted-community pubkeys were launched against self-hosted relay B (…__<community-B-id>.log) with the same failure

Meanwhile the correct per-relay identities (d22e491c, e1db22b5, …) sat unused. Which agent "works" is effectively selection-order luck — in our case Bumble happened to keep a valid pairing while Fizz/Honey did not.

Repro (as observed)

1. Join/configure ≥2 communities in the desktop, each with the default managed agents (distinct keypairs per community are created correctly).
2. Restart agents for community A (e.g. after a relay-side reset, or plain stop/start).
3. Launcher starts buzz-acp for community A using an identity belonging to community C; closed relay A rejects it.

Expected

Agent launch resolves the managed-agent entry by (name, community/relay_url) — never by name alone — so each community's agent always authenticates with that community's keypair.

Workarounds used

• Enrolling the foreign pubkeys as members on the self-hosted relays (makes the misrouted agents connect, but wrong identities then act in the community), or
• Deleting the other community's agent entries from managed-agents.json so only correct candidates remain.

Related observation

An agent created without a relay_url (unscoped) is listed in every community's agent view. If unscoped entries are intended as templates only, hiding them from community rosters would avoid confusion; if they're launchable, they have the same identity-selection ambiguity as above.