fix(desktop): buzz agents draft-create succeeds on relay but fails to trigger Desktop draft review form

[Markus-it-support]

Summary

When executing buzz agents draft-create from an external VPS CLI, the relay accepts the NIP-IA draft event ("accepted": true, kind 9035), but the Buzz Desktop app on macOS fails to receive/render the prefilled draft form for owner review.

Codebase References

Per desktop/src-tauri/src/managed_agents/nest_skill.md and crates/buzz-acp/src/base_prompt.md:

"Agent draft commands add {request_id, action, saved: false} because they only open an owner-reviewed Desktop draft. Buzz Desktop resolves local runtime/provider/model defaults..."

Environment Details

• CLI Host: Ubuntu Linux (Remote VPS)
• Desktop Host: macOS (Buzz Desktop)
• Relay: Managed Relay Server (https://markus-biz.communities.buzz.xyz)

Steps to Reproduce

1. Execute draft-create from a remote VPS with valid BUZZ_PRIVATE_KEY and BUZZ_AUTH_TAG:

   BUZZ_PRIVATE_KEY="<nsec...>" \
   BUZZ_AUTH_TAG='["auth","..."]' \
   ./target/release/buzz agents draft-create \
     --channel "<channel_uuid>" \
     --display-name "Athena AI" \
     --system-prompt "System prompt..."
   

Observe successful relay response:
{"accepted":true,"action":"create","event_id":"8b4b261e...","saved":false}

Open or refresh Buzz Desktop on macOS.

Check Inbox, channel view, and Agents tab.

Expected Behavior
Buzz Desktop should consume the incoming kind 9035 event on its WebSocket connection, apply local defaults, and open a reactive draft approval modal/banner for the workspace owner.

Actual Behavior
No draft review pop-up, banner, or form opens in Buzz Desktop.

The agent appears in the channel member list (Athena AI 🔒 managed by you), but does not populate inside the main Agents tab gallery.

No headless CLI command (e.g. buzz agents approve) exists to save/approve the draft directly from the server side.

Related Work
Related to open PR #3610 (fix(desktop): queue agent draft requests).

[jbforge]

Traced this at origin/main (4d47aa83). The relay is behaving correctly —
the problem is that draft-create has no delivery guarantee at all, so this
sequence can't work today regardless of what Desktop does.

The frame is kind 24200, not 9035. buzz agents draft-create builds a
KIND_AGENT_OBSERVER_FRAME (crates/buzz-core/src/kind.rs:409) — the CLI
asserts this directly in crates/buzz-cli/src/agent_management.rs:210
(assert_eq!(built.event.kind.as_u16(), 24_200)). Kind 9035 is the NIP-IA
archive request, a different feature. Worth correcting since it changes where
to look.

24200 is ephemeral, and ephemeral means never stored. It sits in the
20000–29999 range that kind.rs:396 documents as "Never stored." Two
independent places enforce that:

• crates/buzz-relay/src/handlers/event.rs:680 routes 24200 into
  handle_agent_observer_event (line 943). That function verifies the
  signature, applies a ±5 minute freshness window, checks owner
  authorization, publishes to pubsub, calls
  fan_out_event_to_local_subscribers (line 1089), and replies
  RelayMessage::ok(event_id_hex, true, "") at line 1091. There is no
  database write anywhere on that path.
• Independently, crates/buzz-db/src/event.rs:268 rejects every ephemeral
  kind from storage outright (DbError::EphemeralEventRejected).

So {"accepted":true} does not mean "Desktop received it." It means the
relay verified the frame and fanned it out to whichever subscribers were
connected at that instant. If none were, the frame is simply gone — no
persistence, no retry, no delivery receipt. The CLI prints "Draft sent to
Buzz Desktop for owner review" unconditionally
(crates/buzz-cli/src/commands/agents.rs), which is why this reads as a
Desktop bug rather than a dropped message.

That explains the reported sequence exactly: run draft-create on a remote
VPS, then open or refresh Buzz Desktop. The frame was fanned out and
discarded before Desktop ever connected. Refreshing can't recover it, the
Agents tab can't show it, and as noted there's no buzz agents approve to
fall back on. Today the CLI and Desktop must be connected simultaneously for
a draft to land — that requirement isn't documented anywhere I could find.

On the related PR: #3610 is a real fix for a real bug, but a different
one. It addresses desktop/src/features/agents/useAgentManagement.ts, where
seenRequestIds.current.add(next.requestId) runs before the
pendingRequestId.current === null check — so a second draft arriving while
one is already open is marked seen and discarded permanently. That's the
concurrent-draft drop from #3559. It requires a frame to have been delivered
in the first place, so it won't change this report.

(One more note in case it saves someone time: the app-level
RequestedAgentCreateDialogs.tsx / openCreateAgentEvent.ts pair looks like
the relevant code but isn't on this path. requestOpenCreateAgent has three
callers, all in-app buttons — app/AppShell.tsx:862,
features/channels/ui/ChannelMembersBar.tsx:223, and
features/channels/useWelcomeAgentCreate.ts:48. Nothing relay-side dispatches
that event; CLI-originated drafts arrive via
observerRelayStore.ts → subscribeAgentManagementRequests →
useAgentManagement.ts.)

A durable fix needs persistence. Options as we see them, roughly in
increasing order of cost:

1. Make the CLI honest. fan_out_event_to_local_subscribers
   (handlers/event.rs:241) already computes its recipient list but returns
   (). Returning the count and surfacing it for control-direction frames
   would let draft-create warn "no subscriber was connected — this draft was
   not delivered" instead of reporting plain success. This doesn't fix
   delivery, but it converts a silent loss into an actionable message. Caveat:
   on a multi-node relay a Desktop attached to a different node still receives
   the frame via pubsub, so a zero local count isn't proof of non-delivery —
   the signal would have to be advisory.
2. Persist draft requests so they survive Desktop being closed — either a
   stored kind for the management-request subset or a bounded relay-side
   retention buffer that replays pending drafts on subscribe. This is the only
   option that makes the reporter's VPS workflow work, and it's a protocol
   change, so it wants maintainer direction before anyone writes code.
3. A headless approve path (buzz agents approve), which several remote
   workflows would want anyway, though it's orthogonal to the loss itself.

Happy to implement whichever direction maintainers prefer — we have (1)
mostly scoped already. Mainly wanted the corrected kind and the
no-persistence finding on the record first, since the current framing points
at Desktop rendering rather than at delivery.

[jdrolls]

Root cause from reproducing this today on a self-hosted relay: the desktop's draft trust gate rejects drafts whose sender is not already in the desktop's local managed-agent store.

desktop/src/features/agents/agentManagementBuffer.ts — classifyAgentManagementOrigin returns accept only when (a) the sending agent's pubkey is in the desktop's own ManagedAgent list AND (b) owner + sender share the claimed origin channel. Everything else is reject, silently — the relay has already answered accepted:true ("Draft sent to Buzz Desktop for owner review"), so the sender has no way to learn the draft was dropped.

Repro: provision an agent server-side (own identity, systemd-launched, never created through the desktop), have it run buzz agents draft-create --channel <shared channel> ... → relay accepts, desktop shows nothing, no log the user ever sees. The same command from a desktop-managed agent opens the review form fine.

The trust gate itself seems right (arbitrary identities shouldn't be able to pop forms in the owner's desktop) — the bug is the silent half. Either the relay should validate sender-is-desktop-managed at submission (so the CLI gets a real error), or the desktop should surface rejected drafts somewhere visible (a dismissible "draft from unrecognized agent X was ignored" row). Happy to PR whichever direction maintainers prefer.