[Bug] Agents created outside the current app-managed store do not appear in the Agents tab #3054

Activity

1. davidglogan commented on Jul 31, 2026

   

   davidglogan

   on Jul 31, 2026

   More actions

   Confirming this from a real deployment tonight: stood up an agent (Grok Build, xAI) purely via the external buzz-acp CLI on its own dedicated VM — never touched via the Desktop app at all, by design (our project's security model deliberately keeps every agent's process off the machine running the human's own Desktop client).

   The agent is fully functional at the relay level — correct role: "bot" channel membership, responds to @mentions, introduces itself in group channels, DMs work — but is entirely absent from Desktop's Agents tab, exactly as described here. Took a bit of investigation to confirm this was expected/by-design rather than a misconfiguration on our end (traced it to desktop/src-tauri/src/managed_agents/discovery.rs, which is scoped to locally-launchable runtimes only).

   +1 on option 1 in the expected-behavior list (discover and display externally-managed buzz-acp agents associated with the current relay/community) — for architectures like ours where the agent intentionally never runs on the Desktop machine, there's currently no way to see it in the app at all, only via direct relay queries (buzz messages search --author <pubkey>, buzz channels members, etc.). A read-only "connected ACP clients" view would close that gap without requiring the adopt/import flow in option 2, which doesn't really fit this use case (there's nothing local to adopt — the agent's identity and process both live elsewhere by design).
2. noneymous commented on Aug 13, 2026

   

   noneymous

   on Aug 13, 2026

   More actions

   Can confirm. Wanted my agents to run on another machine, so that they

   • can stay online and keep working when my notebook is shut down
   • can be used via the mobile app
   • are segregated from my notebook environment
   • may have more computing power
   • etc...

   but didn't work out that way. Such agents would just show up like any other human connecting to the community and not be managable/configurable/shareable, etc... I'm a bit surprised that this isn't working yet, as I think it would be the most common configuration.
3. hondoaus commented on Aug 15, 2026

   

   hondoaus

   on Aug 15, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming this from another real self-hosted deployment, with an existing Hermes Agent rather than a Buzz-created runtime.

   Our setup is deliberately split:

   • Buzz relay is self-hosted.
   • The agent (KITT) is a long-running Hermes Agent on a VPS and remains fully owned by Hermes (profile, memory, skills, tools, model, lifecycle).
   • Buzz is only the collaboration/discovery/transport layer; Desktop should not own or spawn the Hermes runtime.
   • KITT has a normal kind:0 profile plus a complete agent-signed kind:10100 record (name, display_name, agent_type: hermes, channel_ids, respond_to, respond_to_allowlist, channel_add_policy).
   • Desktop recognizes KITT as an agent in the channel member UI and, once respond_to=allowlist includes the current user, KITT appears correctly in @ autocomplete.

   However, KITT is still completely absent from the Agents tab because it is not in the local managed-agent store.

   That makes this issue very visible in practice: the remote agent is valid, discoverable, channel-visible and mentionable, but the primary Agents UI makes it look as though it does not exist.

   Strong +1 for displaying relay-visible/external agents in the Agents tab as a distinct non-local type. The key product requirement for us is: visibility and collaboration must not imply local lifecycle ownership. A remote Hermes agent should be shown with its identity/profile/presence/channels, while Start/Stop/Edit-runtime controls remain unavailable unless Buzz actually owns that runtime.

   I would be happy to test any implementation against this Hermes + self-hosted Buzz setup.
4. AlmogBaku commented on Aug 26, 2026

   

   AlmogBaku

   on Aug 26, 2026

   More actions

   Tested macOS workaround for using a Buzz-created identity in an external/native Hermes gateway:

   1. Create the agent normally in Buzz Desktop so Buzz publishes the managed-agent identity/policy.
   2. Copy its pubkey from the Buzz UI.
   3. Stop the Desktop-managed runtime and disable start-on-launch; never run it concurrently with Hermes.
   4. Extract the credentials and configure Hermes with the output:

   #!/usr/bin/env bash
   set -euo pipefail
   
   relay="https://YOUR-COMMUNITY.communities.buzz.xyz"
   store="$HOME/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json"
   
   read -rp "Agent pubkey: " pubkey
   auth_tag=$(jq -r --arg p "$pubkey" '.[] | select(.pubkey == $p) | .auth_tag' "$store")
   private_key=$(security find-generic-password -s buzz-desktop -a secrets -w |
     jq -r --arg k "agent:$pubkey" '.[$k]')
   
   printf 'BUZZ_RELAY_URL=%s\nBUZZ_PRIVATE_KEY=%s\nBUZZ_AUTH_TAG=%s\n' \
     "$relay" "$private_key" "$auth_tag"

   This works because Desktop stores all secrets in the buzz-desktop Keychain entry (account=secrets) as a JSON map keyed by agent:<pubkey>, while auth_tag remains in managed-agents.json.

   Caveat: this relies on internal Desktop storage; the supported agent snapshot export intentionally excludes the nsec and auth tag. A supported adopt flow remains preferable for existing external identities: #6571.
5. WifiDan commented on Aug 27, 2026

   

   WifiDan

   on Aug 27, 2026

   More actions

   Confirming this on a self-hosted setup, hosted relay (not dev-local), Buzz Desktop v0.5.20.

   Ran a real agent (Nous Research's Hermes, via a headless buzz-acp systemd service on our own server) — it's a fully working relay member: correctly authenticated, subscribed to channels, replies to @mentions, participates normally in #general. Desktop's Agents tab and the Huddle agent picker show zero trace of it — only the built-in personas (Fizz/Honey/Bumble) are selectable in Huddle, and there's no way to add or even reference the externally-run agent from either surface.

   This makes an otherwise fully-functional self-hosted agent invisible from the two places a user would naturally look for it. +1 on option 2 (explicit import/adopt flow, preserving the existing identity) — for anyone running agents outside the Desktop-managed lifecycle (systemd service, container, CI job, per docs/remote-agents.md's "any conforming launcher" model), silently creating a duplicate on "adopt" would be worse than the current invisibility, so identity preservation matters here specifically.

   Related from our side: this also blocks Huddle's live-voice feature from working with a self-hosted agent at all, since Huddle can only address agents it can see in the picker.