Owner control commands are unsendable from Buzz Desktop: is_owner_control_command's exact-content + p-tag requirements are jointly unsatisfiable from every composer flow #6014

Activity

1. uevuleocha commented on Aug 20, 2026

   

   uevuleocha

   on Aug 20, 2026

   More actions

   The CLI satisfies both conditions, which localizes the fix to the composer.

   buzz messages send --mention <pubkey> attaches p tags independently of the message text, so a bare !rotate body can carry the required tags. Confirmed on 0.5.17: one CLI send with --content "!rotate" and four --mention flags reached all four agents, and all four harness logs record receipt within 5 ms of each other at the same timestamp.

   That matters for the framing here. The gate is not jointly unsatisfiable in general — it is jointly unsatisfiable from the Desktop composer specifically, because the composer keeps @Name in content while deriving the p tag from it. A client that decouples the two satisfies both conditions today.

   So the smallest fix is on the client side: let the composer attach mention tags without leaving the text in the body, which is what the CLI already does. Alternatively, allow a leading @Name before the command in the matcher. Either one closes it without touching the harness gate's semantics.
2. kaminai0000 commented on Sep 10, 2026

   

   kaminai0000

   on Sep 10, 2026

   More actions

   The "every composer flow" scope in the title no longer holds: the DM composer now produces a satisfying event, and the command fires. The channel/mention flow is still broken exactly as described. Narrowing evidence below.

   DM: works

   Bare !cancel typed into a DM with an agent, no @, no reply. Raw event as stored by the relay:

   kind:    9
   content: "!cancel"
   tags:    [["h", "dfb66e55-…"], ["p", "c10455b3…"]]
   pubkey:  cb422fce…        // owner, matches the harness's --agent-owner

   Content exact ✅ · p tag ✅ → intercepted. Harness log for the same second:

   09:28:15  Prompt on session 36a15e87-…
   09:28:15  conversation turn: session=36a15e87-… model=… platform=acp history=28
   09:28:24  control signal sent to in-flight task (scope-exact)
                 channel=dfb66e55-… scope=conversation mode=Cancel
   09:28:24  Cancelled session 36a15e87-…
   09:28:24  Turn ended: reason=interrupted_during_api_call … tool_turns=9
   

   Sub-second from publish to cancel. No !cancel received but no in-flight task warning, and the agent process was never restarted (same PID before and after, 21h uptime) — the ACP server acknowledged session/cancel inside CONTROL_CANCEL_GRACE, so the SIGKILL fallback never ran.

   Applying this issue's own intercept criterion — an intercepted command produces no reactions, because the handler consumes the event before the turn machinery — here is every event in the channel across the whole exchange:

   time	kind	content	author	tags
   01:28:14	9	從 1 數到 400… (the prompt)	owner	h,p
   01:28:15	7	👀	agent	e
   01:28:15	7	💬	agent	e
   01:28:24	5	(deletion)	agent	e
   01:28:24	9	!cancel	owner	h,p
   01:28:24	5	(deletion)	agent	e

   The 👀/💬 pair and both kind:5 deletions are the prompt's turn choreography, opened at 01:28:15 and torn down when the turn ended. The !cancel event itself draws no reaction of its own — it is consumed, not prompted.

   Channels: still broken, and the failure is a clean dichotomy

   Every owner-authored kind:9 event in a stream channel on the same relay:

   content	starts with @	p tags
   @Agent 打開apple music	yes	1
   @Agent 目前電腦上…	yes	1
   目前電腦上…	no	0
   @Agent 你好嗎	yes	1
   @Agent 請回覆	yes	1
   @Agent 你好嗎	yes	1
   @Agent 目前電腦上…	yes	1

   Perfect anti-correlation: in a stream channel, the p tag and clean content are mutually exclusive. Attempts 1 and 2 in the original report reproduce unchanged. Row 3 is the interesting one — a bare message sent immediately after an addressed one did not retain the p tag, so persistent addressing does not rescue the top-level channel case.

   Likely cause of the divergence

   The original report is dated 2026-08-16 against v0.2.1 / Desktop 0.5.14. Persistent agent addressing landed after it:

   • feat(desktop-messages): keep agents addressed across messages #6315 — keep agents addressed across messages (2026-08-21)
   • feat(desktop): persist agent addressing across composer messages #6714 — persist agent addressing across composer messages (2026-08-25)
   • fix(desktop): retain automatic mentions only in threads #7144 — retain automatic mentions only in threads (2026-09-01)

   That sequence is consistent with what's observed: addressing became a persistent audience carried as a p tag rather than inline text, which is exactly the shape is_owner_control_command wants — and #7144 then scoped automatic retention to threads, which matches row 3 above losing the tag at channel top level.

   Caveat: this is correlation from dates and behaviour, not a bisect. There is a second uncontrolled difference from the original Attempt 4, which used a Desktop-managed local agent; the run above used an externally hosted buzz-acp connecting to the relay as an agent. Either factor could explain the DM difference, and I have not isolated which.

   Suggestion

   Suggested fix 1 (relax the matcher to accept a p-tagged owner message whose trimmed content ends with the command) still resolves the remaining channel case and needs no client change. Suggested fix 3 (document the exact-content requirement) is worth doing regardless — the DM/channel split is invisible from the product, so a user who succeeds in a DM and then fails in a channel has no way to tell why.

   Environment

   block/buzz @ 3c7f288c (v0.5.23, 2026-09-05). Desktop and harness both built from that tree on 2026-09-08; the 14 commits on main since are not included. Self-hosted relay. buzz-acp runs an external ACP server over stdio, launched with --agent-owner <owner-hex> and default --multiple-event-handling (steer). Events read directly from the relay's Postgres events table; timestamps in the event tables are UTC, harness log lines are UTC+8.