[kazemek21]

TL;DR

Adds five owner tools that let an app-hosted agent create, edit, archive, unarchive and delete its signed-in owner's channels and Solo chats. Agents can already read with their owner's access; this adds the matching channel management. The tools reuse the session's existing channel writers and signing/publication admission, and never give the model a signer.

What changes

• Tools: owner_channel_create, owner_channel_update, owner_channel_archive, owner_channel_unarchive and owner_channel_delete (src/buzz-mcp/owner.ts). They are listed only where the existing owner read tools are: bundled-harness runs in communities the BUZZ_OWNER_MCP_COMMUNITIES build flag names. Plugins, installed harness plugins, plugin tools and external apps still get no owner access.

• Writers: src/features/agents/owner-channels.ts drives the owner's own session services: the outbox and channelWrites for create, channelDetails.save for edits, and channelLifecycle.run for archive, unarchive and delete. Each checks active() before signing and again before publication. Details and lifecycle retain their own uncertain-publication state, even if the session closes after dispatch.

• Admission: ownerMutationActive (owner-access.ts) is that active(). It is true only while all of these hold:

  • the calling turn (the host's own turn signal and check, via appClient);
  • the binding the write was admitted on (same session, viewer and community);
  • the agent's run lifetime on this host (runner.controller.signal, captured in Runner.handleFor);
  • the agent's recorded owner.

  A harness that cannot report whether its turn is still running gets no writes.

• Create: takes a caller-chosen UUID.

  • A call with no operation is a new create. If Buzz already has a queued create for that ID, the call resumes it; if the relay's signed metadata already has the channel, the call confirms it.
  • To resume, the caller passes the operation an earlier answer returned. That call only resumes the journaled command or confirms the channel from the relay's metadata. It never signs another create. If Buzz no longer holds the operation and the relay has no channel yet, the answer is unconfirmed, with that operation and a pointer to owner_channel_get.
  • The same ID with other details, a system-channel command, additional initial members, or another create's operation is a conflict.
  • The owner is Owner; the agent is not added.

• Update: takes the version that owner_channel_get now returns (the metadata event ID). Editable settings and version come from the same fresh metadata. It never saves over a newer version.

• Lifecycle: exact IDs only, limited to archive, unarchive and delete. DMs and system channels are refused.

• Outcomes: confirmed (read back), rejected (nothing published; reason is one of busy, conflict, cancelled, denied, refused or failed) or unconfirmed (may have been published). Anything that reached the relay transport is never reported as rejected.

Tests

• owner-channels.test.ts drives a real relay session (outbox, channel writes, details and lifecycle) against a fixture relay that applies 9007/9002/9008 to its own signed records. It covers:
  • confirmed create, Solo create, repeat and conflicting IDs, and a lost acknowledgment that a call with the returned operation resumes without re-signing;
  • a separate call with the operation after a possible send, once the receipt is cleared and the relay shows no channel: it answers unconfirmed and signs nothing, then confirms once the channel appears;
  • relay refusal and refusal to resume broader queued system/member-bearing creates;
  • Stop, turn end, account switch and agent retirement before queueing and while signing, each with nothing published;
  • versioned edits, stale discovery values, stale versions, and unconfirmed edits that later settle or stay busy;
  • the full create → inspect → update → archive → archived discovery → unarchive → delete sequence; busy; unconfirmed lifecycle; system-channel refusal;
  • caller retirement during authorization before signing for update, archive, unarchive and delete, plus session closure after an update reaches transport;
  • the admission predicate on its own.
• Mutation checks confirmed these tests fail when admission always passes, the journal resume is removed, the "may have been sent" classification is removed, the version check is removed, or the no-replacement guard for a resumed operation is removed.
• owner.test.ts, app-client.test.ts and service.test.ts cover argument validation (including operation), exact forwarding, the write-aware release message, host-supplied caller wiring, and refusal without a host caller.

Not covered

• Exercised only in automated tests: not yet driven in the running app or against a live relay.
• If a caller retries without operation after the receipt is gone and the relay shows no channel, the call is treated as a new create. The tool description tells agents to pass operation when they resume.

🤖 Generated with Claude Code

🤖 Updated by Codex (gpt-6.1-sol) on behalf of kylez.

[kazemek21]

Closing without merging. Every owner-channel action in this PR, including archive, unarchive and delete, runs through the owner-access layer, which #3123 removed. Bringing it back would mean reintroducing owner authority, and that work is stopped for now.

Agents' own channel_archive, channel_unarchive and channel_delete tools already exist on main and are unaffected. The earlier cancellation check this PR adds to the shared lifecycle has no current caller on main, so it isn't worth landing alone. The branch is kept as is.

— Posted by Claude (claude-opus-5-5) on behalf of kylez