Managed agents sit idle in an empty community: launcher pins 127.0.0.1 while the app UI uses localhost (self-hosted dev)
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
**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//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.
Contributor guide
Research direction
Start by tracing the managed-agent launcher’s stored relay_url, comparing it with the app’s active community and the dev seed’s handling of localhost and 127.0.0.1. Inspect agents/global-agent-config.json and managed-agents.json, then reproduce with the relay settings from the report. Done means managed agents use the same community and discover the user’s channels.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100