Persona respond-to edits never reach the running agent: card shows anyone, harness starts owner-only

[xoxoskeleton]

Summary

Editing an agent's respond-to setting on its persona card updates the persona and leaves the running agent on its old gate, permanently. The card shows one mode, the harness enforces another, and no amount of saving or restarting reconciles them.

We hit this across two Macs: an agent whose card read anyone (later allowlist with four keys) started with respond_to=owner-only on all six of its buzz-acp starting: lines, including after a full quit and reopen of Buzz Desktop. Every mention from a non-owner was dropped at author_allowed while the agent was online and healthy, and answering its owner normally.

Desktop 0.5.3, reproduced against upstream b1b283c.

Root cause

personaManagedAgentUpdate (desktop/src/features/profile/ui/UserProfilePanelUtils.ts:262) is the function that pushes a persona edit down onto the linked managed-agent instance. It propagates displayName, systemPrompt, model, envVars and runtime-derived commands. It does not propagate respondTo or respondToAllowlist, even though UpdateManagedAgentRequest accepts both (desktop/src-tauri/src/managed_agents/types/requests.rs:251).

The write path for the persona side is apply_persona_behavior (requests.rs:40), which by design touches definition fields only. The instance side is populated by resolve_mint_behavioral_defaults (types.rs:931), which reads the definition's respond_to at mint time only. There is no later reconcile: respond_to appears zero times in reconcile.rs.

The spawn env is built from the instance record:

// desktop/src-tauri/src/managed_agents/runtime.rs, build_respond_to_env
set.push(("BUZZ_ACP_RESPOND_TO", record.respond_to.as_str().to_string()));

ManagedAgentRecord::respond_to is #[serde(default)] and RespondTo's #[default] is OwnerOnly, so an instance row where the field was never written also deserializes silently to the most restrictive mode.

Observed on disk, ~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json:

row	respond_to	definition_respond_to
definition row (no pubkey)	owner-only	allowlist (4 keys, correct)
instance row (agent pubkey)	owner-only, empty allowlist	absent

Why it took three days to find

The drop is invisible at the default log level. inbound author gate — dropping event is tracing::debug! (crates/buzz-acp/src/lib.rs) while the harness logs at INFO. A correctly delivered and correctly dropped mention leaves zero trace, so it is indistinguishable from an event that never arrived. We chased relay delivery, mention p-tags, the Desktop mention picker and is_dm_channel fail-closed behaviour before reading the agent's own startup line, which is the only place the effective gate is stated.

Reproduce

1. Create an agent from a persona while the persona's respond-to is owner-only.
2. Edit the persona card's respond-to to anyone (or allowlist) and save.
3. Restart the agent, or fully quit and reopen Buzz Desktop.
4. Read the newest buzz-acp starting: line in ~/Library/Application Support/xyz.block.buzz.app/agents/logs/<pubkey>__<hash>.log.

Expected: respond_to=anyone. Actual: respond_to=owner-only, indefinitely.

Fix

PR attached: propagate respondTo / respondToAllowlist in personaManagedAgentUpdate, mode and allowlist together, treating a null persona respondTo as unset.

Two adjacent things worth considering separately:

1. useAgentManagement.ts:48 hardcodes respondToAllowlist: [] when relaying an inbound agent-management update request, so a buzz agents draft-update --respond-to allowlist can only ever fail the backend's non-empty-allowlist validation.
2. Log the resolved gate at INFO on spawn and surface it on the card ("running as: owner-only" next to the configured value). A security gate whose UI cannot be trusted to describe the process, and whose drops are invisible at the default log level, is expensive to diagnose. Promoting the drop line to INFO, or adding a periodic dropped-author count, would have made this a five-minute bug.

Workaround

Until the fix lands, the only reliable local remedy is editing the instance row's respond_to in managed-agents.json with Buzz Desktop fully quit, then reopening. Verify by the next buzz-acp starting: line; the card is not evidence.

[ohadive]

🤖 Comment posted by Fizz, an AI agent, on behalf of @ohadive.

Reproduced on Desktop 0.5.3 (macOS): persona card said anyone (saved 11:28 local), instance record in agents/managed-agents.json still owner-only, and across a full day every wake traced back to an owner mention — mentions from three other members (two Desktop-managed agents, one CLI-signed) never triggered one.

One additional datapoint for the mint-time-only analysis: the app rewrites managed-agents.json at session spawn. After a harness session started at 20:53:06, the file's mtime was exactly 20:53:06. Practical consequence: manually patching the instance record only sticks if the edit is made while the app is fully quit; edits made while it runs are liable to be clobbered and/or never loaded. That's also the repro path we used to get respond_to: "allowlist" onto disk at all — which the wake path then ignored anyway (see #1743 / #3858; cold spawns appear owner-gated regardless of the instance record's respond_to).

Cross-ref: #2501 reports the same non-propagation from v0.4.23.

[mckeejessica0]

日志级别建议线上默认 info 吗 💡

[hooperjohn8]

😄🔥 SSR/CSR 切换有没有闪烁

[shanegringcertainlycoop]

Another reproduction, on a hosted-relay community (*.communities.buzz.xyz), Desktop on macOS (Darwin 24.6.0):

• Owner flipped a managed agent's respond-to from owner-only to anyone via the Desktop draft-review flow and saved; re-saved multiple times, including from a freshly recreated draft. Card-side save appeared to succeed each time.
• The running agent kept behaving owner-only: three well-formed DM mentions from a non-owner community member (2026-08-07 16:42, 16:46, 17:08 UTC) never triggered a session, while byte-for-byte structurally identical mentions from the owner woke it instantly every time.
• Corroborating symptom: the non-owner's @-mention autocomplete never listed this agent while every other agent appeared — consistent with the effective gate still being owner-only regardless of what the card shows. (Possibly the same ownership filtering as Cross-owner agent mentions are impossible: candidates filtered by local ownership, and eligibility reads a kind (10100) nothing publishes #3776.)

Matches the report here exactly: the save succeeds on the persona/card side, nothing reconciles it down to the running instance, and the drop is silent so it looks like relay non-delivery. Current workaround on our side is the agent polling for its own missed mentions and replying out-of-band.

[electro56435]

Confirmed in Buzz Desktop 0.5.8 (desktop-v0.5.8, commit f3de860).

personaManagedAgentUpdate() still transfers the name, prompt, model, environment variables, and runtime commands. It does not transfer respondTo or respondToAllowlist.

The definition fields remain mint-time defaults. An app restart does not copy them to an existing keyed instance. Thus, a successful draft review can update the definition while the current pubkey keeps its old access rule.

Apply an access-rule change to the selected keyed instance. If the user edits only future defaults, label that scope in the form.

[jjalora]

Corroborating this from a live multi-agent deployment (dafaistudio community, self-hosted relay, Buzz Desktop 0.5.x, three built-in-persona HQ agents Bumble-HQ / Fizz-HQ / Honey-HQ). Same root cause, with two additions that generalize the bug beyond "starts owner-only."

The stuck value is not always owner-only — it's whatever the instance already had. Bumble-HQ and Honey-HQ (both builtin: personas) were stuck at respond_to=allowlist(1), not owner-only. Every buzz-acp starting: line across ~10 restarts over two days showed respond_to=allowlist(1), while the owner repeatedly set "Who can send instructions" → Anyone in the UI. managed-agents.json confirmed the desync — the instance records kept:

{ "display_name": "Bumble-HQ", "respond_to": "allowlist",
  "respond_to_allowlist": ["fd24ebdc…"], "is_builtin": false, "is_active": true }
{ "display_name": "Honey-HQ",  "respond_to": "allowlist",
  "respond_to_allowlist": ["fd24ebdc…"], "is_builtin": false, "is_active": true }

fd24ebdc… is Fizz-HQ's pubkey (Fizz was correctly respond_to=anyone). So the two agents answered only owner + siblings + Fizz; every ordinary member was dropped at author_allowed while the agents were online and healthy — indistinguishable from "agents ignoring people." This exactly matches #3030 (built-in allowlist(1) divergence) and is the same mechanism as this issue.

The verified code gap is still present. personaManagedAgentUpdate (desktop/src/features/profile/ui/UserProfilePanelUtils.ts:262) propagates name, systemPrompt, model, envVars, and runtime command/args/mcp to the linked instance — but not respondTo/respondToAllowlist, so a persona-side access edit never reaches the instance record the harness spawns from. (UpdateManagedAgentInput accepts both fields, and the direct update_managed_agent merge at desktop/src-tauri/src/commands/agent_models.rs:835-853 writes them correctly — so the Members-sidebar "Manage agent access" dialog and the persona/profile-card path diverge, and built-in-persona agents hit the broken one.)

Only a direct managed-agents.json edit fixed it — set respond_to: "anyone", clear the allowlist, quit Buzz first so it respawns from the new value. No sequence of UI save + restart changed the record.

One more finding worth flagging for triage: in this deployment the stale allowlist[Fizz] was written programmatically by the agents themselves (they have permission_mode=bypassPermissions + dev-mcp shell/file tools and edited the record directly), not by a human using the UI. That's a separate governance problem I've filed at #5626, but it's relevant here because #4487 means that once an agent (or any non-UI writer) narrows the instance record, the owner cannot undo it through the UI — the persona-card edit silently no-ops on respondTo. The fix for #4487 (propagate respondTo/respondToAllowlist in personaManagedAgentUpdate, and reconcile persona vs instance) is what makes the UI an authoritative recovery path again.

Repro is 100% on built-in-persona agents: card/dialog shows Anyone, buzz-acp starting: shows allowlist(1) (or owner-only), and the two never reconcile across quit/reopen.