Managed agents sit idle in an empty community: launcher pins 127.0.0.1 while the app UI uses localhost (self-hosted dev)

[JGroutsis]

Describe the bug
On a self-hosted dev instance, every Desktop-managed agent (the built-in Welcome Team personas and user-created agents) connects and authenticates, then discovers zero channels and sits idle — while the Desktop UI itself works normally in the same instance. Cause: community identity is host-derived, the dev seed registers each host spelling as its own community, and the managed-agent launcher pins agents to ws://127.0.0.1:PORT while the app's active community is localhost. The agents land in a different, empty community, and fail-closed tenancy correctly gives them nothing.

Steps to reproduce

1. just dev on macOS with the relay port remapped in .env (BUZZ_BIND_ADDR=0.0.0.0:3100, RELAY_URL=ws://localhost:3100).
2. Complete onboarding in the Desktop app; create channels, or use existing ones — the UI works.
3. Let onboarding create the Welcome Team agents, or create a managed agent of any runtime.
4. Watch the agent log under Application Support/<bundle-id>/agents/logs/.

Expected behavior
The managed-agent launcher uses the same relay URL / community as the app's active community — or the dev seed maps loopback spellings (localhost, 127.0.0.1, with and without port) onto one community — so agents see the same channels the user does.

Version and platform

• Buzz version: 0.5.0 (tag checkout, commit 4a977c5, just dev)
• OS: macOS 15.7 (Apple Silicon)

Logs / additional context
Every managed agent, on every start and restart:

INFO buzz_acp: connected to relay at ws://127.0.0.1:3100
INFO buzz_acp: discovered 0 channel(s)
WARN buzz_acp: no channel subscriptions resolved — agent will sit idle

communities table after onboarding — one community per host spelling:

3c89e6ae-…  localhost
129cbfbe-…  127.0.0.1
e2f45882-…  127.0.0.1:3100
(+ localhost:3100)

Setting BUZZ_RELAY_URL: ws://localhost:3100 in agents/global-agent-config.json env_vars does not help — the per-agent stored relay_url wins. Restarts do not help.

Workaround: run agents through the standalone buzz-acp harness with BUZZ_RELAY_URL=ws://localhost:3100 (works, auto-reconnects, replies in-channel). Hand-editing each agent's relay_url in managed-agents.json with the app quiesced also appears viable.

This cannot bite hosted or single-hostname production deployments — it is specific to self-hosted dev where one machine has several names. Happy to provide more logs or DB output.

[JGroutsis]

Root cause found. Two components disagree about host identity:

1. buzz-core's normalize_relay_url (crates/buzz-core/src/relay.rs) rewrites every loopback host to 127.0.0.1 — including localhost.
2. The managed-agent runtime builds its runtime key with that normalizer (desktop/src-tauri/src/managed_agents/runtime_types.rs:22) and then passes the normalized URL to the child as BUZZ_RELAY_URL (desktop/src-tauri/src/managed_agents/runtime.rs:550,581).
3. The relay resolves community strictly from the connection host ("row zero", crates/buzz-relay/src/tenant.rs; communities.host is UNIQUE(lower(host)), no aliases).

So with a workspace of ws://localhost:3100, the UI operates in the localhost:3100 community while every managed agent is spawned pointing at ws://127.0.0.1:3100 — a different, empty community — and logs discovered 0 channel(s) — agent will sit idle.

Editing per-agent relay_url in managed-agents.json cannot work around it: effective_agent_relay_url deliberately ignores the stored pin (#2122).

Suggested fix: normalization is fine for cache/dedup keys, but the URL handed to the child (and anything that reaches the relay's host-based tenant resolution) should preserve the host the workspace was configured with. Alternatively, the relay could normalize loopback hosts the same way at community resolution, so both sides agree.

All the code paths above are unchanged through v0.5.2. Workaround that survives upgrades, verified working: rename the dev community's host to 127.0.0.1:3100 (the host the launcher actually emits) and point the workspace at ws://127.0.0.1:3100 — all four managed agents then discover their channels.