Desktop (new build): local agent only wakes on owner @mentions, no 'respond to' setting left to allow other channel members #8684

Activity

1. varavienthan-source commented on Nov 2, 2026

   

   varavienthan-source

   on Nov 2, 2026

   More actions

   Same problem here, on a small marketing team using a Block-hosted community.

   Setup

   • Buzz Desktop 0.7.0-preview.230.1 (xyz.block.buzz.desktop), macOS, Apple Silicon
   • Two local agents started by the app: one Claude Code, one Codex
   • A teammate has their own Claude Code agent in the same community

   What happens

   • My agents reply only to my @mentions. When my teammate picks my agent from the @ list in a shared channel, no turn starts. Their agent behaves the same way towards me.
   • All three agents are channel members with the Participating role and show as online.
   • The agent profile's Settings tab shows only Workspace, Sessions, Public key and Delete. There is no "Who can send instructions" option, and the saved agent settings only contain model, effort and scope.

   What I tried

   • Stable v0.5.28 still has "Manage agent access..." with Only me, Selected people and Anyone. But with the current npm adapters (claude-agent-acp 0.100.0, codex-acp 2.5.0), buzz-acp models --json fails with error -32602 "Invalid params" and the Model list is empty. Pinning claude-agent-acp@0.88.0 and codex-acp@2.1.1 brings the models back, in case that helps anyone who needs to fall back.

   Request
   Could the per-agent "Who can send instructions" setting (Only me, Selected people, Anyone) come back for agents created in the new build? We would especially like Selected people, so teammates and their agents can start turns with each other in a shared channel. A rough timeline would also help us plan. Thank you!
2. fgdghooperator commented on Nov 6, 2026

   

   fgdghooperator

   on Nov 6, 2026

   Last edited by fgdghooperator

   More actions

   Field report from a production deployment on Buzz Desktop v0.7.0-preview.245.1: we reproduced this and isolated the failure after mention delivery, not in autocomplete or relay routing.

   Sanitized topology:

   • two distinct Windows human identities used Buzz Desktop only as operator clients;
   • an always-on macOS host ran three heterogeneous agent runtimes;
   • all participants used the same self-hosted Buzz relay.

   For the failing non-owner invocations we verified, layer by layer:

   1. the kind:9 message persisted at the relay;
   2. it contained the correct p tag for the selected agent;
   3. the macOS host received the event;
   4. runner dispatch and mention delivery ran;
   5. the target agent was ready;
   6. admission then stopped at fromOwner(...) in src/features/agents/owner-attestation.ts, so no agent turn began.

   The relevant admission paths are the exact recorded owner, a valid owner attestation to that owner, and—for bundled runtimes that pass workflow context—a verified workflow-attribution path. A legitimate human operator of the remote host has no normal teammate/operator admission path, so a correctly addressed mention can be silently discarded after delivery.

   As a diagnostic proof only, we added a narrowly scoped local delegated-operator check for agents belonging to one designated owner. That immediately allowed both Windows operators to wake all three macOS-hosted agents. We then restored every agent's kind:30177 policy to respond_to: "owner-only" and reverified it at the relay; the same six operator/agent paths still passed. This rules out an accidentally broad anyone policy and supports an authorization-policy defect rather than a relay or mention-picker defect.

   We also completed an unattended cold reboot of the host. The relay stack, host networking, agent supervisor, and all three runtimes recovered, after which the same two-operator × three-agent matrix passed again. The invoking Windows clients did not host or start those runtimes locally.

   I would not propose hard-coding delegated keys or changing the meaning of owner-only. The two generic product shapes that seem consistent with existing Buzz semantics are:

   1. restore an owner-signed per-agent invocation policy in the new Desktop — Only me / Selected people / Anyone — and have bundled/generic runtime admission honor it; or
   2. introduce a distinct owner-signed delegated-operator capability that is explicit, scoped, revocable, and distinguishable from allowing anyone to prompt the agent.

   Which policy model do maintainers want for the 1.0 Desktop/runtime path? If direction is confirmed, I can contribute a focused regression test and/or PR rather than upstreaming our diagnostic local allowlist.

   Suggested regression coverage would separate mention creation, relay delivery, and runtime authorization across one primary human account, two explicitly authorized users, one unauthorized user, and a remotely hosted agent. Each authorized user should start exactly one turn; the unauthorized user should be rejected; strict owner-only should remain strict without delegation; and reconnect/restart should not change the verdict.

   Related discovery/p-tag issues such as #3277 and #4535 are useful context, but they are not the root failure in this reproduction: autocomplete, p tagging, relay receipt, and runner delivery were all already working.