buzz-acp: DM replies anchor to the latest message instead of the thread root — every exchange nests one level deeper
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
Research direction
Start in crates/buzz-acp/src/queue.rs and inspect the DM branch of resolve_reply_anchor alongside the documented human-facing reply-anchor rule. Confirm that threaded DM replies use thread_tags.root_event_id rather than the latest event, and verify that repeated exchanges no longer create nested sub-threads.
Written by the indexing model from the issue text.
Description
Symptom
In a 1:1 DM with a managed agent, once a thread exists, every agent reply anchors to the human's latest comment rather than the thread root. Each exchange therefore nests one level deeper — the user has to click-expand a sub-thread of a sub-thread of a sub-thread to follow a simple back-and-forth conversation with their own agent.
Root cause
crates/buzz-acp/src/queue.rs — the human-aware reply-anchor logic documents the right intent directly above the code:
Human-facing turns are anchored so replies stay readable at layer 1:
- in a thread → anchor to the thread ROOT (no depth-2 nesting)
…and resolve_reply_anchor implements exactly that for group channels. But the DM branch contradicts it:
let reply_anchor = if is_dm {
thread_tags
.root_event_id
.is_some()
.then(|| last_event.event.id.to_hex()) // ← anchors to the LATEST message, not the root
} else {
resolve_reply_anchor(...) // ← group channels: anchors to ROOT
};
When the triggering DM message is inside a thread, the anchor is last_event.event.id — the user's newest comment — so the agent's reply becomes a child of a child, and the nesting compounds every round.
Propose
In DMs, match the documented layer-1 rule: anchor to thread_tags.root_event_id when inside a thread (same as the group-channel human path). Worth discussing whether top-level DM exchanges should thread at all — a 1:1 DM arguably reads best flat, with threading reserved for explicit user-initiated threads — but the root-anchoring fix alone eliminates the compounding sub-chat nesting.
Observed on a self-hosted relay (ghcr.io/block/buzz:main 2026-07-24, desktop 0.4.24), desktop-managed agents, default settings. Sibling issues: #2270 (thread deafness without re-mention), and the DM mention-gate issue filed alongside this one.
- Dominant language
- Rust
- Stars
- 33.7k
- Forks
- 4.4k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 239
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from block/buzz
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
workflow_sink's mention parser never masks code regions — @name inside a code span wakes the agent Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 Half a day Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100