block / block/buzz

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

Open
#3,505 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.