buzz-acp: stream-channel @mentions can be stored and visible in feed, yet never traverse steer/wake path for a subscribed managed agent

[GeeWow]

Summary

A managed buzz-acp agent can be subscribed to a normal stream channel while an owner's @mention is stored and returned by the message and mention-feed commands. The running agent session still does not enter the steer or wake path.

The affected channel appears in the active buzz-acp subscription log. Comparable mentions in a second subscribed stream channel do reach the steer path.

Environment

• Buzz Desktop managed agent using buzz-acp
• ACP agent runtime on Linux
• Mention subscription mode with owner mentions enabled
• Relay address and machine-specific settings omitted from this public report

Channels

• Affected stream channel: <affected-stream-channel>
• Working control stream channel: <control-stream-channel>
• Channel identifiers omitted

What was verified

1. The affected channel is a stream channel.
2. The agent is a member of the affected channel.
3. The active buzz-acp log records a subscription to the affected channel.
4. The log also records a subscription to the control channel.
5. Owner mentions in the affected channel are stored on the relay and returned by the message command.
6. The mention-feed command also returns those mentions.
7. Comparable owner mentions in the control channel trigger steer handling.
8. The affected-channel mentions produce no equivalent steer or wake log entries.

Reproduction

1. Start a managed agent subscribed to two stream channels.
2. Send an explicit owner @mention in the affected channel.
3. Confirm that the message and mention-feed commands return the event.
4. Observe that the running agent does not wake or steer.
5. Send a comparable owner @mention in the control channel.
6. Observe that the agent wakes and the log records steer activity.

Expected behavior

An explicit owner mention in any actively subscribed stream channel should enter the same wake and steer path.

Actual behavior

The affected-channel mention is present at the relay and feed layers, but it never reaches the runtime wake and steer path. A comparable mention in the control channel works.

Log evidence

The active log records subscriptions to both channel identifiers. For the control channel, it also records:

• non-cancelling steer ack received
• ack=Ok(Err(ExpectedRunIdMissing))
• signal_fallback=true
• control signal sent to in-flight task

Those wake and steer entries are absent for the affected-channel mentions.

Scope

Membership, channel type, subscription state, relay storage, and mention-feed visibility were verified. The remaining failure appears between channel-scoped mention delivery and the runtime control-signal path.

Related issues

• Provider-backed agent config saves do not trigger redeployment #2798 covers stale live runtime state after provider-backed configuration saves.
• [Bug] buzz-acp reply delivery is implicit — Sonnet-class agents answer in session text and every reply is silently dropped #2698 covers dropped reply delivery despite runtime activity.
• Agent @mentions silently fail when mentioned agent is offline #1743 covers mention delivery while an agent is offline.
• buzz-acp: agent in a 1:1 DM only wakes on an explicit @mention — plain DM messages are dropped by require_mention #2860 covers mention filtering in a different channel type.

Suggested investigation

Trace channel-scoped event delivery through mention filtering and into the steer or control-signal path. Compare an affected subscribed stream channel with a working subscribed stream channel.

The exact relay, channel, and event identifiers were removed from this public report. I can provide them privately to maintainers if needed.

[nik-maniya]

Adding a matching data point from a different setup (2026-07-30), same signature: a mention that was fully delivered but never traversed the wake path.

• Managed buzz-acp agent ("Checker"), member of the channel, session running.
• Another agent posted a kind-9 message in that channel with Checker's pubkey in its p tags (event 1ed899e7d5ec037b6c6e65f359353164ba46f6afc51cac01d796050adf9e8301).
• The event is stored on the relay, returned by buzz messages get, and shows up in the agent's own buzz feed get --types mentions output — delivery was end-to-end.
• The agent session was never woken for it; the message was only discovered ~20 minutes later via a manual channel-history fetch.

One caveat for triage: at the time of the missed mention the agent's access scope may still have been owner-only (it was changed to "Anyone" shortly after, and the mention author was not the owner). If the trigger layer is designed to silently drop published mentions from non-permitted authors, that interacts confusingly with the feed (the mention is visible in the agent's own mentions feed but never fires, with no signal to the sender). If not, it's the same stored-but-never-steered path described in this issue. Mentions from the agent's owner in the same channel wake it reliably.

[alirezarezvani]

Likely another instance of this, on Desktop 0.5.3 (2026-08-01): a channel mention was sent to an agent that was online per relay presence at that moment; the send receipt confirmed the mention tag. The agent never processed it — no reaction over 11 minutes of polling, while the message was stored and visible in the channel. An identical re-mention 11 minutes later was answered within 7 seconds.

Frequency data point: one occurrence in roughly 30 mentions to that agent pool over one night, so intermittent rather than systematic — which matches a wake-path miss rather than a subscription gap. The same workaround as for offline loss applies (re-send the mention once), but for a live, delivery-confirmed mention there is no signal at all that it was dropped.

[jamesjlopez]

Additional macOS reproduction for the pre-harness boundary in this issue.

• Managed agent: @agentclientprotocol/codex-acp 1.1.7, with subscribe=Mentions dedup=Queue meh=Steer ignore_self=true respond_to=anyone.
• After a fresh restart, its buzz-acp log records a successful relay connection and subscription to the affected stream channel.
• An owner-authored, explicitly addressed channel mention was accepted and remains queryable from the relay.
• The harness log has no inbound event, queue, wake, or steer entry for that probe.
• A same-shape control probe to a different freshly restarted Codex managed agent produced the expected relay-accepted reply.

This is distinct from #3282/#6345: those begin after an event reaches the harness and is misrouted around steering; this reproduction has no observed relay EVENT entering the harness.

To make the next reproduction isolate the boundary, I opened #6991. It adds structured debug fields for: channel subscription REQ sent, channel EVENT received, and event forwarded to the harness, plus a websocket-level forwarding test. Exact event/channel identifiers and a sanitized log window are available privately to maintainers.

[jamesjlopez]

Follow-up: we now have a second independent macOS reproduction, which makes this look less like one agent's stale process state.

A different managed agent identity, with a different runtime/model configuration, received multiple owner-authenticated channel mentions in the same subscribed stream channel. Each probe was accepted and remains queryable from the relay with the expected channel, thread, target-pubkey, and agent-address tags. The agent emitted no reply.

We repeated this after an explicit Desktop stop/start of that agent; the same correctly addressed probe still produced no response. This rules out the task prompt, mention formatting, and an in-process stale session as practical explanations. A separate managed agent in the same channel had previously replied to the same shape of probe.

We still cannot observe whether the relay delivered an EVENT on the affected WebSocket subscription, so this does not prove relay fan-out versus harness forwarding. It does strengthen the pre-harness reproduction: a stored, correctly addressed event can disappear before any harness wake/steer evidence.

The small trace/test PR #6991 remains the proposed way to make the next reproduction decisive: log channel REQ sent, relay EVENT received, and event forwarded to the harness. Exact event IDs and sanitized local log windows remain available privately to maintainers.