buzz-acp: thread-reply @mention to an idle agent is swallowed by the steer path (ExpectedRunIdMissing, no turn in flight)

[egouilliard-leyton]

Summary

A single @mention of a managed buzz-acp agent in a thread reply is silently swallowed when the agent is completely idle — no turn in flight, nothing queued, nothing running.

The mention is received and routed down the steer path (meh=steer, the default). Steer then looks for the run it is supposed to steer, finds none, fails with ExpectedRunIdMissing, and the event is consumed as a control signal. No turn is ever started, no reply is posted, and nothing is surfaced in the UI — the mention just disappears.

A new top-level message in the same channel works every time. Only thread replies are affected.

This is closely related to #3071 and #3176, but the trigger here is materially different and I think narrows the root cause — see Why this isn't a duplicate below.

Environment

• Buzz Desktop 0.4.26 (AppImage), Ubuntu 24.04.3 LTS, x86_64
• Agent runtime: @agentclientprotocol/claude-agent-acp 0.63.0, Node v24.11.0
• Relay: self-hosted community relay (address omitted from this public report)
• Agent config, verbatim from the harness startup line:

subscribe=Mentions dedup=Queue meh=Steer ignore_self=true context_limit=12
max_turns_per_session=0 presence=true typing=true memory=true
model=(agent default) permission_mode=bypassPermissions respond_to=owner-only

Pubkeys, channel IDs, event IDs and the relay address are redacted below.

Reproduction

1. Start a managed buzz-acp agent with default meh=steer and let it settle to idle.
2. Confirm it is genuinely idle — no turns for several minutes.
3. In a channel it is subscribed to, @mention the agent as a reply inside an existing thread.
4. Observe: no response, no typing indicator, no error in the UI.
5. @mention the same agent in a new top-level message — it responds normally.

Evidence

Harness log, ~/.local/share/xyz.block.buzz.app/agents/logs/<pubkey>__<...>.log.

Note the timestamps. The agent came online at 08:18:36 and logged nothing at all for the next five minutes. There was no possible in-flight turn:

08:18:33.775  INFO  buzz_acp: agent_pool_ready agents=24
08:18:34.914  INFO  buzz_acp: connected to relay at <relay>
08:18:36.030  INFO  buzz_acp: subscribed to channel <channel-A>
08:18:36.030  INFO  buzz_acp: subscribed to channel <channel-B>
08:18:36.031  INFO  buzz_acp: presence set to online

        ── 5m 08s with no log output whatsoever; agent idle ──

08:23:44.715  WARN  buzz_acp::acp: goose-native steer: no active_run_id at write time
                    (no session/update seen yet) — falling back to cancel+merge
08:23:44.715  INFO  buzz_acp: non-cancelling steer ack received channel=<channel-A>
                    event_id=<redacted> ack=Ok(Err(ExpectedRunIdMissing))
                    release_withheld=true drop_withheld=false signal_fallback=true
08:23:44.716  INFO  buzz_acp: control signal sent to in-flight task channel=<channel-A>
                    mode=Steer

control signal sent to in-flight task is emitted for an agent that has been idle for over five minutes. After this, the log is silent — no session start, no prompt dispatch, no reply.

This is reproducible and not a one-off. Same signature, same channel, three separate occasions across two days:

2026-07-27 19:42:23  ack=Ok(Err(ExpectedRunIdMissing))
2026-07-27 23:00:45  ack=Ok(Err(ExpectedRunIdMissing))
2026-07-28 08:23:44  ack=Ok(Err(ExpectedRunIdMissing))

Why this isn't a duplicate

• [Bug] Agents never respond in voice huddles: transcripts arrive but every utterance hits ExpectedRunIdMissing and cancels the in-flight run #3071 (voice huddles) has an identical log signature, but its stated mechanism is rapid, short utterances arriving faster than a run ID can be exposed — a race against an actively starting turn. It is framed as voice-specific.
• buzz-acp queue mode batches independent requests and destroys per-event reply identity #3176 notes steer failing on a six-event fixture sent one second apart — again, concurrent events racing a run.
• buzz-acp: stream-channel @mentions can be stored and visible in feed, yet never traverse steer/wake path for a subscribed managed agent #3105 is about mentions that never reach the steer path at all. Here the mention does reach it.

In this report there is no concurrency at all: one mention, one idle agent, five minutes of quiet either side. That suggests the precondition for entering the steer path is wrong independently of any race — the harness treats a thread-reply mention as "mid-turn" when there is demonstrably no turn. If so, #3071's voice symptom may be one visible consequence of a more general defect rather than the defect itself.

Expected behavior

A mention that arrives when no turn is in flight should start a new turn, whether it is a top-level message or a thread reply.

If the steer path is entered and returns ExpectedRunIdMissing, the event should fall back to normal dispatch rather than being consumed. Silently dropping user input is the worst possible outcome — nothing is shown in the UI, so the message simply vanishes with no indication anything went wrong.

Workaround, and its cost

Setting BUZZ_ACP_MULTIPLE_EVENT_HANDLING=queue avoids the steer path and restores thread mentions. But per #3176 queue mode batches pending events into a single turn, so this trades silent message loss for loss of per-event reply identity. Both defaults are lossy in different ways; there is currently no mode that is simply correct for a single thread mention to an idle agent.