Inbox replies to managed agents can disappear before delivery

[skulk-and-quarrel]

Summary

A human reports that replying to a managed agent through Inbox can cause the new DM message to appear briefly in the conversation and then disappear before the agent handles it.

Expected

An Inbox reply should persist in the DM timeline and be delivered once to the managed-agent harness (or show an explicit delivery/error state).

Actual

The reply is shown in the agent DM, but sometimes the agent does not process it and the message later disappears from the timeline.

Steps reported

1. Open an Inbox notification for a managed agent's message.
2. Reply from Inbox.
3. Observe the reply appear in the agent DM.
4. In the failing case, the agent never responds and the reply disappears.

Evidence and scope

• Reported from the macOS Buzz app on 2026-08-11 around 23:30 Pacific.
• This was not reproduced deterministically.
• A control Inbox reply did arrive at the harness with the expected channel (h) and agent mention (p) tags, so the failure may be specific to an Inbox-reply reconciliation path or an intermittent delivery race rather than all DM delivery.
• No private message content or account identifiers are included here.

Suggested investigation

Trace one Inbox reply event end-to-end: local optimistic insertion -> signed event submission -> relay acknowledgement/storage -> DM subscription/cache reconciliation -> harness receipt/enqueue. Preserve the event id at each stage, and ensure a failed delivery is surfaced rather than removing the message.

[skulk-and-quarrel]

Root cause found

This is a desktop DM timeline-projection bug, not a relay deletion or a managed-agent delivery failure.

I inspected the affected DM's signed events locally: the Inbox message is persisted as a normal channel message, the ACP harness receives it, and the agent publishes a normal kind 9 NIP-10 reply (e tag with marker reply). The reply is present in the agent activity/transcript surface, but the DM conversation projection drops it.

The failure chain is:

1. buzz messages send --reply-to deliberately builds a NIP-10 reply (CLI send path).
2. The channel-window DB query intentionally returns only top-level rows (plus broadcast depth-1 replies), excluding ordinary thread replies (predicate).
3. The desktop live subscription places a reply in the per-thread cache, then returns before adding a non-broadcast reply to the channel-window projection (subscription path).
4. Inbox treats a DM as a full-channel conversation, but its context hook clears/fails to fetch the reply subtree in that mode and renders only the top-level channel-window messages (full-channel branch, rendered source).

So a new Inbox/DM refresh replaces the local view with the authoritative top-level-only window; the signed agent reply (and, depending on local state, the earlier local row) vanishes from the DM UI even though it was persisted and the agent acted on it.

Proposed narrow fix: for DM Inbox context, fetch the recent channel content without the top-level projection so normal replies are included; also retain live non-broadcast replies in the channel projection for DMs. I’m preparing that focused desktop patch with coverage.

[skulk-and-quarrel]

Just adding for completeness: I'm not a bot.

My "Honey" is writing all of the above after I noticed the bug and asked them to work on it. I asked them to work on the PR too. It should follow soon. Honey is running on sol 5.6 with xhigh thinking.

[skulk-and-quarrel]

Implemented as draft PR #5635. It hydrates recent DM Inbox context with ordinary replies and keeps the selected DM subscription live, with a regression test for the top-level-window omission.

[skulk-and-quarrel]

Scope correction from the signed DM trace: the screenshot’s original message is event ab5f18b..., a top-level channel event (no NIP-10 e tag). The later Inbox action is ba47ef9..., a normal reply to that root. The current draft PR #5635 addresses the separate symptom where NIP-10 agent replies are omitted from Inbox DM detail; it does not yet reproduce or prove a fix for the top-level root becoming temporarily absent after later activity. I have marked the PR body as draft/WIP accordingly and will add a reproduction before requesting review.

[skulk-and-quarrel]

Final signed-event correction and implemented fix

This supersedes my earlier event identification and narrow root-cause comments.

The message highlighted in the screenshot is event 929865d3c0…, authored from Inbox. Its signed tags contain only the DM channel's h tag. It has no participant p tag and no NIP-10 e tag.

The direct cause is that Inbox used the raw sendChannelMessage path with only explicitly typed @mention pubkeys. With no explicit mention, it produced an h-only DM event. The normal DM composer uses useSendMessageMutation, which implicitly adds the other DM participants as p tags. Because the agent's p tag was absent, the harness was not addressed; that accounts for no automatic working reaction, no activity, and no reply.

The Inbox raw path also skipped the shared channel-window cache mutation used by the conversation view, which explains why its local row could be displaced after later activity. Separately, ordinary NIP-10 agent replies were omitted by the stream-style top-level window that Inbox DM detail consumed.

Draft PR #5635 now covers the complete sequence:

• sends Inbox messages through the shared channel mutation, including implicit DM recipients and cache reconciliation
• retains live normal replies for DMs and fetches recent flat DM context
• adds a browser regression that asserts the participant p tag and verifies the Inbox message survives a newer conversation send
• includes a unit regression for an agent NIP-10 reply omitted from the top-level window

just ci and the focused E2E regression both pass on 45c60632ff8c69b8ebe895fbefc4696a2dd43112.