buzz-acp: agents accept messages but never dispatch to harness — dispatch loop appears to wedge minutes after startup (all harness types, v0.5.3)

[Haltzeus]

Buzz bug report — OmniRoute Operator (custom ACP harness) stopped processing messages

Buzz version: v0.5.3 (Windows)
Agent: OmniRoute Operator, custom ACP harness (bridge validated independently — see "Harness is not the problem" below)
Date symptoms began: 2026-08-02 (worked correctly 2026-08-01)
Scope update (2026-08-02 ~21:00): the dispatch failure is NOT specific to the custom harness — see Bug C below; claude-agent-acp and codex-acp agents show identical pool-init-without-dispatch, and one agent gets stuck in setup-listener mode.

Summary

The agent receives messages (relay subscription active, membership/channel events arrive, agent pool initializes in response to an incoming message) but never dispatches a prompt to the harness. No agent_returned, no error, no requeue — the harness's ACP stdio stays silent. The same harness processed owner DMs correctly the previous day.

Timeline (all times UTC, from agent logs)

2026-08-01 — WORKING

• 12:07–13:22: Owner DMs processed end-to-end; two successful runs (~6 min each), replies posted in channel. Agent command at the time was incorrectly set to claude-agent-acp.cmd (unauthenticated) — expected "Authentication required" errors observed, then harness switched to custom bridge and everything worked.

2026-08-01 13:39 — custom harness confirmed healthy

• agent_cmd=C:\WINDOWS\system32\wsl.exe bash -lc /home/webgive/stacks/crewai-orchestrator/bridge/acp_bridge.py
• model=crewai-fixed-lineup picked up from _meta.models in initialize response.

2026-08-02 10:43 — first silent failure

• Owner (me) sent a DM. Log shows ZERO events at that timestamp — no channel event, no batch, nothing. Presence showed online.

2026-08-02 14:27 — restart after config change

• Restarted agent (stop/start). Startup banner still shows respond_to=owner-only despite "Who can send instructions" being set to "Selected people" and saved (see Bug B below).

2026-08-02 15:02:39 — pool initializes but no dispatch

• ~1 min after owner message, all 10 pool agents initialize (agent initialized ... agent=0..9, agent_pool_ready agents=10), then nothing. No session/prompt reaches the harness (no activity on its stdio), no agent_returned, no queue/requeue lines.

2026-08-02 20:27 — @mention test, total silence

• Owner sent @OmniRoute Operator Create a file called world5.txt ... in the original DM channel (the one that worked on 2026-08-01). Log shows no new lines at all in the following minutes.

Bug A: messages accepted but never dispatched to harness

Symptoms as above. Notably the failure mode differs by send:

• Some sends produce zero log lines (20:27)
• One send produced pool init but no dispatch (15:02)
• All produce no user-visible response, no error surfaced anywhere in the UI

Hypotheses I cannot verify from outside: a wedged internal queue after 2026-08-01's auth-failure requeue loop (attempts 1–6 of 10 logged before agent stop), DM/mention routing change between 08-01 and 08-02, or stale channel state (the agent is subscribed to 4 channels: 2c7038a9, 84721bf3, b11e7898, d1821d0d — the original working DM is 84721bf3).

Bug B: "Who can send instructions" does not propagate to runtime

• Set to "Selected people" (3 agents added via the people picker), clicked Save changes, restarted the agent 6+ times across the day.
• Every startup banner still shows respond_to=owner-only.
• Consequence: agent-to-agent delegation is silently dropped — another agent (Codex Builder) added this agent to a group chat and sent a brief at 14:42; only the membership notification: subscribing to new channel line appears, the message itself is never processed.

Harness is not the problem

The custom ACP bridge is independently verified:

• 16/16 unit tests; live JSON-RPC transcript tests (initialize / session/new / session/prompt / session/cancel) all pass outside Buzz.
• Streams sessionUpdate chunks correctly; handled a full real run on 2026-08-01 with 2,422 streamed chunks.
• Responds to session/set_config_option (visible in logs) — so Buzz CAN reach it.
• The failure is upstream of the harness: no session/prompt ever arrives on its stdio during the silent windows.

Environment

• agent_cmd: C:\WINDOWS\system32\wsl.exe bash -lc /home/webgive/stacks/crewai-orchestrator/bridge/acp_bridge.py
• model: crewai-fixed-lineup (advertised via _meta.models; also via session/new configOptions per ACP v1)
• Startup flags: subscribe=Mentions dedup=Queue respond_to=owner-only permission_mode=bypassPermissions agents=10
• Relay: wss://cenenta.communities.buzz.xyz (two WebSocket "Connection reset without closing handshake" events on 08-01, both auto-recovered)

Reproduction

1. Create custom ACP harness agent, verify owner DM works (08-01 behavior).
2. Next day, send owner DM → silence.
3. Restart agent → send again → pool may initialize, still no dispatch.
4. Set "Who can send instructions" → "Selected people", save, restart → banner still respond_to=owner-only; agent messages still dropped.

Bug C: identical dispatch failure on built-in ACP agents (claude-agent-acp, codex-acp)

The failure is not harness-specific — it is in buzz-acp's message→dispatch path. Observed same evening, all owner DMs, all respond_to=owner-only so owner messages should pass the filter:

• Claude Dev (claude-agent-acp v0.64.0, agents=10): owner DM at 20:46 → all 10 pool agents initialize (agent_pool_ready agents=10) → no session/prompt dispatch, no reply. Agent restarted at 20:51:10; a second owner message after restart → silence. NOTE: the 20:46 message also arrived during the previous run's idle_timeout=900s window (agent had been idle since 15:01, i.e. ~5h45m), so dispatch after long idle is also implicated.
• Codex Builder (codex-acp v1.1.7, agents=2): owner DM at 20:47 → pool re-inits (agent_pool_ready agents=2) → no dispatch. Earlier at 14:42 this agent DID process an owner message and replied — the only successful dispatch all day across all agents. (That success was ~3.5 min after a restart.)
• Claude Dev setup-mode wedge (possibly separate): across restarts at 09:42, 09:49, and 14:27 the agent entered setup-listener mode ... requirements=1 and never exited it — subscribing to channels but processing nothing. Only the 15:01 restart (after re-authenticating Claude Code in the terminal) reached normal startup. If setup mode is supposed to be resolved by in-app auth UI, there was no user-visible prompt in any of those three windows.

Pattern: the only successful dispatch of the day happened within ~4 minutes of an agent restart. Every message sent to an agent that had been running for longer (minutes to hours) produced pool-init-only or total silence. This points at the event-processing/dispatch loop wedging shortly after startup, not at harnesses, auth, or channel subscriptions (which all initialize cleanly).

Requested investigation

1. Why does an incoming owner message trigger pool init but no session/prompt dispatch (15:02, 20:46, 20:47 events)?
2. Why do some messages produce zero log lines at all (10:43, 20:27)?
3. Does the dispatch loop wedge after some time/idle period? (Only success today was ~4 min post-restart; failures at 14 min, ~1 min, ~5h45m post-start.)
4. Why doesn't the "Selected people" setting reach the runtime respond_to flag?
5. Why did Claude Dev sit in setup-listener mode across three restarts with no UI prompt to resolve it?
6. Is there a way to inspect/flush the agent's internal event queue (dedup=Queue)?