Managed-agent instance config (kind:30177) never syncs cross-device, causing every member device to auto-offer a duplicate/unconfigured local agent

[priyanshusaleshandy]

Summary

When a persona (e.g. an agent named "Fizz") is created and properly configured on one device (Owner's host — provider/model/harness set, e.g. Codex), every other device that simply joins the same channel/community independently offers to run its own separate local instance of that same persona, defaulting to "needs setup on this device." If that device has any agent runtime enabled (e.g. the Buzz Agent runtime, which cannot be toggled off in the UI), it auto-spawns a local buzz-acp process in a setup-mode listener state — which then sends spurious "Fizz needs configuration" replies into the channel, competing with the properly-configured instance on the intended host machine.

This defeats the "one shared team agent" use case entirely — every team member's device ends up needing its own separate, fully-duplicated configuration (including a separate provider login, e.g. a separate codex login/ChatGPT session per device) just to avoid broken replies, even though only one device is meant to actually host the agent.

Root cause (traced in source)

Two relay sync paths are asymmetric:

• Persona definition (kind:30175) — propagates to every member device unconditionally. apply_inbound_persona (desktop/src-tauri/src/commands/personas/inbound.rs, ~line 342-364) inserts the persona locally on any device that receives the event, regardless of BackendKind.
• Managed agent instance record (kind:30177) — carries the actual backend field (BackendKind::Local vs BackendKind::Provider{id, config}) and is the thing that would tell another device "this persona is already actively hosted elsewhere." apply_inbound_managed_agent (same file, ~line 376-405) is an explicit no-op when there's no local match, per the existing comment: "an agent that does not already exist locally has no secret key to run with, so inserting a secretless shell would be useless and misleading."

Because only the definition (kind:30175) propagates and never the instance/backend state (kind:30177), every device that receives the persona has no way to know it's already hosted elsewhere. ManagedAgentRuntimeStatus.localSetup (desktop/src/shared/api/types.ts) and agentCommunityAvailability() (desktop/src/features/agents/managedAgentRuntimeStatus.ts, ~line 9-25) compute "needs setup on this device" purely from local state — there's no cross-device ownership/exclusivity check anywhere in reconcile.rs, discovery.rs, or persona_events.rs.

Notably, the recently-shipped "explain open agent access" work (#2561) reframes respond-to for a provider-backed (remote) agent — "Anyone can use this agent to access the server it runs on" — which reads as if it already solves centralized/shared hosting. It doesn't: that wording only describes where the owner's own instance computes (local machine vs. a buzz-backend-* remote provider). It has no effect on whether other member devices independently offer/spawn their own separate instance of the same persona — because, per the above, BackendKind/instance state never syncs to them in the first place.

Steps to reproduce

1. Device A (owner): create a persona ("Fizz"), configure it fully (harness = Codex, model = gpt-5-codex, logged in), set respond_to: Anyone. Confirm it replies correctly to @Fizz messages.
2. Device B (a different machine, logged in as a different community member, or even the same identity paired to a second device): join the same channel that "Fizz" is a member of. Do not touch Agents/Compute settings on Device B at all.
3. Observe: Device B's Agents/Compute page lists "Fizz — NEEDS SETUP ON THIS DEVICE" despite never having been asked to host it.
4. If Device B has any agent runtime enabled (Buzz Agent toggle — could not find a way to disable this in the UI), a buzz-acp process spawns locally in setup-mode and independently replies to @Fizz mentions in the shared channel with "Fizz needs configuration — set the provider field / set the model field," even though Device A's instance is fully configured and already replying correctly. Both replies land in the same thread, and which one wins is a race.

Expected behavior

A persona that already has an actively-hosted managed instance elsewhere (owner-configured, respond_to set to share access) should not cause other member devices to auto-offer/auto-spawn their own competing local instance. At minimum, the setup-mode listener should not fire (or should not post visible "needs configuration" replies into shared channels) on devices that are not the persona's designated host.

Impact

This is the core blocker for using Buzz as a "one shared team agent, everyone just talks to it" tool (the natural Discord-bot-style expectation) — currently every team member's machine needs its own fully separate agent configuration (including separate provider credentials/login) to avoid broken/competing replies, which does not scale to a team and contradicts the stated design intent behind #2561's "provider-backed (remote) agent" access model.

Environment

• Buzz Desktop, self-hosted relay deployment (on-prem Rust relay, own Postgres/Redis/MinIO)
• Reproduced on main at commit 4672ee5 (post-fix(desktop): explain open agent access #2561)
• macOS and Windows desktop clients

[jbforge]

Confirming the source trace in this report still holds at origin/main
(4d47aa83), and adding one detail that argues this needs a design
decision rather than a patch:

The asymmetry is deliberate and documented in the code itself. The
doc comment on apply_inbound_managed_agent
(desktop/src-tauri/src/commands/personas/inbound.rs:376-381) states the
no-match no-op is intentional — "an agent that does not already exist
locally has no secret key to run with, so inserting a secretless shell
would be useless and misleading. This diverges from the persona path, which
DOES insert on no match (personas are secretless definitions)."

That reasoning is sound for the record, but it also means the backend
kind never reaches other devices, and the backend kind is the only thing
that could answer "is this persona already hosted somewhere?" So the gap
this issue describes is a consequence of a correct secrets decision, not a
bug in the merge itself — which is why patching apply_inbound_managed_agent
to insert on no-match would be the wrong fix.

Confirming the rest of the trace:

• apply_inbound_persona (inbound.rs:342-364) does insert on no match,
  unconditionally, on any receiving device.
• agentCommunityAvailability
  (desktop/src/features/agents/managedAgentRuntimeStatus.ts:9-24) returns
  "Needs setup on this device" purely from runtime.localSetup, with no
  input from any remote host/ownership signal.

What seems to be missing is a separate, secretless "this persona has a
designated host" signal — something a device can learn from the relay
without implying it can run the agent. That is additive rather than a change
to the existing merge semantics, and it would let
agentCommunityAvailability distinguish "needs setup here" from "hosted
elsewhere, nothing to do."

One adjacent note: PR #3441 (open) reworks the managed-agent
key-generation boundary and adds a community-scoped identity index built
from retained owner-authored kind:30177 links. It targets duplicate
minting rather than the host-exclusivity question here, but it touches the
same cross-install kind:30177 reconciliation surface and is probably worth
coordinating with.

One caveat on scope: I have not reproduced the cross-device symptom on a
two-device setup — the above comes from reading the code at origin/main,
so it is worth confirming against a real reproduction before building on it.