[Bug] <Desktop: agent respond_to / allowlist edits don't persist — buzz-acp always starts with owner-only>

[georgerous]

Summary

Editing an agent's "Who can talk to this agent" setting in the Desktop UI
(changing respond_to to Anyone or Allowlist, and adding a human pubkey to
the allowlist) does not persist to the value the buzz-acp harness actually
uses. The harness keeps starting with respond_to=owner-only, so non-owner
members can never interact with the agent, regardless of what the UI shows.

Environment

• Buzz Desktop v0.4.23 (macOS, Apple Silicon)
• Self-hosted relay: ghcr.io/block/buzz:mainIRE_RELAY_MEMBERSHIP=true)
• Agent: a custom agent (not a built-in Welcome Team persona), runtime claude

Steps to reproduce

1. Create a custom agent (owner-only by default).
2. Open its config → Who can talk to this ae
   (also tried Allowlist + add a member's pubkey). Save.
3. Restart the agent (also tried: stop → edit
4. Have a non-owner member @mention the agent in a shared channel.

Expected

The agent responds to the member (Anyone), or to allowlisted members (Allowlist).

Actual

• The member gets no response.
• The buzz-acp starting log line always sho.
• This reproduced identically on the hosted (Builderlab) relay too, so it is not
  relay-specific.

Evidence

In ~/Library/Application Support/xyz.block.bnts.json,
after changing the UI to "Anyone", the agent's definition entry shows a
desync:

"respond_to": "owner-only",          // v
"definition_respond_to": "anyone",   // what the UI wrote          ✅
"respond_to_allowlist": []           // sng a member ❌

So the UI writes definition_respond_to, butrom
respond_to (unchanged) and respond_to_allowlist (never populated). There are
effectively three out-of-sync states: **UI shig file
has definition_respond_to set but respond_to stale, and the running
harness uses owner-only.

Harness log:

buzz-acp starting: ... respond_to=owner-o

Workaround (confirms the root cause)

Editing managed-agents.json by hand wit
respond_to: "allowlist" and adding the member pubkey to
respond_to_allowlist in the agent's entries reopening
the app the harness starts correctly:

buzz-acp starting: ... respond_to=allowlist(1)

The app did not revert the manual edit, so the config file is the source of
truth; the UI edit path is what fails to writ
respond_to_allowlist.

Impact

Custom agents cannot be shared with other community members through the UI at
all — they silently stay owner-only. Only a manual file edit works.

[Chessing234]

Fixed in https://github.com/block/buzz/pull/ — definition respond-to now propagates to linked instances.

[Chessing234]

Fixed in #2505 — definition respond-to now propagates to linked instances.