fix(desktop): dial managed agents on the configured relay URL, not the canonical runtime key

[lewiswang0516]

Fixes #2444

Problem

Since #2122 (shipped in desktop v0.4.23), every managed-agent spawn path passes ManagedAgentRuntimeKey.relay_url - the canonical identity form - to the child as BUZZ_RELAY_URL. The canonicalizer folds every loopback spelling to 127.0.0.1, but the relay derives the community boundary from the Host header. So with a community configured as ws://localhost:3000:

• the UI posts messages into the localhost:3000 community
• every agent connects to the 127.0.0.1:3000 community, which is empty

Each agent logs discovered 0 channel(s) and no channel subscriptions resolved - agent will sit idle, shows as online, and silently never answers a mention. Full diagnosis with DB evidence is in #2444.

This also contradicts the contract documented on buzz_core::relay::normalize_relay_url itself:

Connection code may retain the configured URL; this canonical form is for identity, receipts, status and deduplication.

Fix

Keep the canonical key for identity, receipts, and log paths. Dial the caller-supplied requested URL:

• spawn_agent_child dials its relay_url parameter verbatim; runtime_key stays identity-only
• start_managed_agent_process, start_pair, and the launch restore path pass their already-resolved requested URL instead of key.relay_url
• reconcile_managed_agent_runtimes forwards the requested community URL to start_pair instead of the canonical echo
• probe_agent_relay_access probes over the requested URL, so the spawn-eligibility probe hits the same community the child will join
• start_pair now fills requested_relay_url in its status rows, and the Active Communities settings card prefers requestedRelayUrl for start/stop/restart, so a manual restart re-dials the configured URL

Testing

• cargo test --manifest-path desktop/src-tauri/Cargo.toml --lib: 1560 passed
• cargo clippy --all-targets and cargo fmt --check on the Tauri crate: clean
• tsc --noEmit and biome check on the changed frontend file: clean
• Honest gap: no new automated test covers the spawn wiring itself, since spawn_agent_child forks a real child process. Verified the failure mode end to end on the affected machine (v0.4.23, local relay): before the fix, children spawn with BUZZ_RELAY_URL=ws://127.0.0.1:3000 (checked via ps eww) and discover 0 channels; the configured community URL is ws://localhost:3000.

A relay-side follow-up worth discussing separately (also in #2444): folding loopback spellings into one community key on the relay, and surfacing the agent-idle state in the UI instead of only in the log.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 46a7820d0d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Retain the requested relay URL across status refreshes

For a community configured as ws://localhost:3000, start_pair initially returns the raw URL, but the status event immediately invalidates the runtime query and list_managed_agent_runtimes returns only the canonical key (ws://127.0.0.1:3000). Once that refresh occurs, this fallback sends the canonical URL on a later Start/Restart (for example after a failed or stopped harness), so the child again dials Host 127.0.0.1 and is placed in the wrong community. Persist the configured URL with the runtime or recover it from the configured community before issuing lifecycle actions.

AGENTS.md reference: AGENTS.md:L120-L120

Useful? React with 👍 / 👎.