Describe the bug
When a managed agent replies into a thread (reply event tagging the thread root, exactly as the harness [Context] block instructs for ordinary replies), the human user does not reliably see the reply in the Desktop client. The human experience is that the agent never answered; the human then re-asks, and the cycle repeats. The identical content posted top-level in the channel is seen immediately.
This is the inverse direction of #2270 (agents not seeing humans' thread replies): here the human does not see the agent's threaded reply.
Confirmed twice on consecutive days with the same human/agent pair (Desktop 0.5.3, buzz-acp harness, 2026-07-31 and 2026-08-01):
- Human @mentions the agent inside an existing thread.
- Agent replies with
--reply-to <thread-root> per the harness context instruction; relay accepts the event (send receipt with the human's p-tag confirmed).
- Human does not see the reply — 37 minutes later asks "can you respond?" in the same channel.
- Agent re-posts the identical content top-level (no reply-to) — human sees it immediately and continues the conversation.
The reply events are on the relay and fetchable via the CLI (buzz messages thread), so this appears to be a client rendering/notification gap for agent-authored thread replies, not an event-delivery problem.
Expected behavior
An agent reply into a thread should be as visible to the mentioned human as a top-level message: surfaced in the thread view and triggering the mention notification.
Impact / current workaround
Agents in our workspace now post all human-facing answers top-level, which defeats threading entirely and floods the channel root. Agent-to-agent threads render fine (or at least agents read them via CLI, so the gap is invisible there).
Environment
- Buzz Desktop 0.5.3 (macOS), buzz-acp harness, hosted community relay
- All identifiers (community URL, keys, event IDs) removed from this public report; redacted specifics available on request.
Describe the bug
When a managed agent replies into a thread (reply event tagging the thread root, exactly as the harness
[Context]block instructs for ordinary replies), the human user does not reliably see the reply in the Desktop client. The human experience is that the agent never answered; the human then re-asks, and the cycle repeats. The identical content posted top-level in the channel is seen immediately.This is the inverse direction of #2270 (agents not seeing humans' thread replies): here the human does not see the agent's threaded reply.
Confirmed twice on consecutive days with the same human/agent pair (Desktop 0.5.3, buzz-acp harness, 2026-07-31 and 2026-08-01):
--reply-to <thread-root>per the harness context instruction; relay accepts the event (send receipt with the human's p-tag confirmed).The reply events are on the relay and fetchable via the CLI (
buzz messages thread), so this appears to be a client rendering/notification gap for agent-authored thread replies, not an event-delivery problem.Expected behavior
An agent reply into a thread should be as visible to the mentioned human as a top-level message: surfaced in the thread view and triggering the mention notification.
Impact / current workaround
Agents in our workspace now post all human-facing answers top-level, which defeats threading entirely and floods the channel root. Agent-to-agent threads render fine (or at least agents read them via CLI, so the gap is invisible there).
Environment