[Bug] Desktop 0.4.23 spawns managed agents on ws://127.0.0.1:3000 while the community uses ws://localhost:3000 - agents silently stop responding

[lewiswang0516]

Summary

On desktop v0.4.23 (installed DMG, macOS), managed agents are spawned with BUZZ_RELAY_URL=ws://127.0.0.1:3000 even though the active community is configured as ws://localhost:3000. Because the relay derives the community boundary from the Host, localhost:3000 and 127.0.0.1:3000 are two fully isolated communities. The result: the UI posts messages into the localhost:3000 community while every agent sits in an empty 127.0.0.1:3000 community, so agents never see any message and never reply. There is no error anywhere - the only hint is a low-key log line in the agent log.

Environment

• Desktop app: v0.4.23, installed from DMG (GUI launch), macOS (Darwin 25.5)
• Relay: local dev relay at port 3000 (just relay)
• Community config in the app (localStorage buzz-communities): relayUrl: "ws://localhost:3000"
• No BUZZ_RELAY_URL in the app process environment, no launchctl env

Steps to reproduce

1. Run a local relay on port 3000.
2. In the desktop app, use a community configured as ws://localhost:3000, create channels, add managed agents to a channel.
3. Install/launch desktop v0.4.23 from DMG and let it restore the managed agents.
4. Mention an agent in the channel.

What happens

• The user's messages land in the localhost:3000 community (verified in the relay DB: events.community_id maps to the localhost:3000 row in communities).
• Every spawned buzz-acp child has BUZZ_RELAY_URL=ws://127.0.0.1:3000 (verified via ps eww). Their membership discovery (kind 39002 query) runs against the 127.0.0.1:3000 community, which is empty, so each agent logs:

INFO buzz_acp: discovered 0 channel(s)
WARN buzz_acp: no channel subscriptions resolved - agent will sit idle

• Agents show as online (presence is set) but never respond to anything.

Notes on the source of the rewrite

• The agent records in managed-agents.json have an empty relay_url, so the spawn falls back to the workspace relay (effective_agent_relay_url in desktop/src-tauri/src/relay.rs).
• On current main, the fallback chain (workspace override from apply_workspace -> env -> build-time -> DEFAULT_RELAY_WS_URL) is all ws://localhost:3000, and the frontend passes the stored community relayUrl unchanged. I could not find the localhost -> 127.0.0.1 rewrite on main, so it seems specific to the 0.4.23 build (repeated agent restarts always produce 127.0.0.1, so it is not a launch-order race).
• An earlier build on the same machine spawned agents with ws://localhost:3000 (visible in older agent logs), so this looks like a regression introduced in or shortly before 0.4.23.

Why this is nasty to debug

1. Nothing fails loudly. The agent connects, authenticates, sets presence to online, and then silently subscribes to nothing.
2. localhost vs 127.0.0.1 is invisible in the UI. The user sees online agents in the member list that simply never answer.
3. Setting BUZZ_RELAY_URL as a per-agent env var is rejected (it is on RESERVED_ENV_KEYS, which is reasonable), so the only workarounds are the per-agent Relay URL field in the Advanced section, or changing the community relay URL - the latter silently forks the community and hides all previous history.

Suggested fixes

1. Find and remove the localhost -> 127.0.0.1 rewrite in the agent spawn path so the child relay URL always matches the workspace relay the UI uses.
2. Consider normalizing loopback hosts (localhost, 127.0.0.1, [::1]) to one canonical community key on the relay side, since they are the same machine and the split is never what a local user wants.
3. Make the idle state visible: when an agent discovers 0 channels, surface a warning in the desktop UI (the log line is easy to miss), since an online-but-deaf agent looks identical to a working one.