Symptom
In a 1:1 DM channel with a managed agent, the agent does not see or answer plain messages — every single message must explicitly @mention it, even though the DM has exactly two participants. Replying to the agent inside a DM thread behaves the same way: no @, no answer.
Expected: a DM is addressed to the counterparty by definition. Chat platforms don't require @-mentioning your DM partner per message, and the mention requirement is invisible — the agent just looks unresponsive.
Root cause
The mention gate is a single global flag with no channel-type awareness:
crates/buzz-acp/src/config.rs (subscription_rules): let require_mention = !config.no_mention_filter; is applied uniformly to every target channel — DM channels included. SubscribeMode::Mentions is the default the desktop uses for managed agents.crates/buzz-acp/src/filter.rs (match_event): re-checks the p tag against the agent pubkey; no mention → dropped.
Notably the harness does know the channel is a DM further down the pipeline — queue.rs branches on channel_type == "dm" for reply anchoring and prompt hints — the DM fact just doesn't participate in the trigger decision.
Safety-wise, auto-responding in DMs appears already bounded: DM turns are restricted to the owner and verified siblings (#2591), so exempting DMs from the mention gate would not open agents to arbitrary third-party prompting.
Propose
Exempt channel_type == "dm" channels from require_mention (subscription filter and match_event), so agents treat any owner message in a 1:1 DM as addressed to them. Group channels keep the existing mention gate unchanged.
Related: #2270 tracks the sibling problem in group-channel threads (agents go deaf in threads they've joined unless re-mentioned). This issue is scoped to DMs only, where the addressed-by-definition argument is strongest.
Observed on a self-hosted relay (deploy/compose derivative, ghcr.io/block/buzz:main 2026-07-24, desktop 0.4.24) with desktop-managed agents at default settings.
Symptom
In a 1:1 DM channel with a managed agent, the agent does not see or answer plain messages — every single message must explicitly @mention it, even though the DM has exactly two participants. Replying to the agent inside a DM thread behaves the same way: no @, no answer.
Expected: a DM is addressed to the counterparty by definition. Chat platforms don't require @-mentioning your DM partner per message, and the mention requirement is invisible — the agent just looks unresponsive.
Root cause
The mention gate is a single global flag with no channel-type awareness:
crates/buzz-acp/src/config.rs(subscription_rules):let require_mention = !config.no_mention_filter;is applied uniformly to every target channel — DM channels included.SubscribeMode::Mentionsis the default the desktop uses for managed agents.crates/buzz-acp/src/filter.rs(match_event): re-checks theptag against the agent pubkey; no mention → dropped.Notably the harness does know the channel is a DM further down the pipeline —
queue.rsbranches onchannel_type == "dm"for reply anchoring and prompt hints — the DM fact just doesn't participate in the trigger decision.Safety-wise, auto-responding in DMs appears already bounded: DM turns are restricted to the owner and verified siblings (#2591), so exempting DMs from the mention gate would not open agents to arbitrary third-party prompting.
Propose
Exempt
channel_type == "dm"channels fromrequire_mention(subscription filter andmatch_event), so agents treat any owner message in a 1:1 DM as addressed to them. Group channels keep the existing mention gate unchanged.Related: #2270 tracks the sibling problem in group-channel threads (agents go deaf in threads they've joined unless re-mentioned). This issue is scoped to DMs only, where the addressed-by-definition argument is strongest.
Observed on a self-hosted relay (deploy/compose derivative,
ghcr.io/block/buzz:main2026-07-24, desktop 0.4.24) with desktop-managed agents at default settings.