Describe the bug
An agent on a custom ACP harness that reports steering_supported=false is subscribed to a channel and shown as online, but never receives any mentions. No error surfaces anywhere — the agent simply stays silent forever. Agents whose harness reports steering_supported=true receive mentions in the same channel normally.
I hit this with a custom harness wrapping gemini-cli (gemini --acp, v0.53.1). The Gemini CLI itself is fine — see "Ruled out" below.
Evidence
Three agents, same community, all subscribed to the same channel, all subscribe=Mentions:
| Agent |
harness |
steering_supported |
receives mentions? |
| ChatGPT |
@agentclientprotocol/codex-acp |
true |
yes |
| Claude |
@agentclientprotocol/claude-agent-acp |
true |
yes |
| Gemini |
gemini-cli (custom harness) |
false |
no |
The two working agents log delivery activity on every mention:
INFO buzz_acp::acp: steer success: renewed hard deadline (7200s from now)
INFO buzz_acp: non-cancelling steer ack received channel=<CHANNEL_ID> event_id=...
INFO buzz_acp::queue: extending in-flight deadline by 7200s + 100s buffer channel_id=<CHANNEL_ID>
The Gemini agent, in the same channel over the same period, logs nothing at all after startup:
INFO buzz_acp: buzz-acp starting: ... subscribe=Mentions ...
INFO buzz_acp: agent initialized agent=0 name="gemini-cli" steering_supported=false
INFO buzz_acp: agent_pool_ready agents=10
INFO buzz_acp: connected to relay at wss://<RELAY>
INFO buzz_acp: discovered 2 channel(s)
INFO buzz_acp: subscribed to channel <CHANNEL_ID>
INFO buzz_acp: presence set to online
<-- no further lines, across many mentions over multiple hours -->
Every mention delivery path that appears in the working agents' logs goes through steer. That suggests mention delivery is gated on steering support, and harnesses that report steering_supported=false fall through with no fallback and no warning.
To reproduce
- Register a custom harness for an ACP agent that does not support steering (e.g.
gemini --acp, gemini-cli 0.53.1).
- Create an agent using that harness and add it to a channel.
@mention the agent in that channel.- The agent shows online and healthy; its log records nothing; no reply ever arrives; no error is raised.
Expected behavior
Mentions should be delivered to agents regardless of steering support — steering is an optimisation for interrupting/updating an in-flight turn, not a prerequisite for starting one. Failing that, Buzz should surface a clear readiness error (like it does for missing adapters/logins) rather than showing the agent as online and healthy.
Ruled out — the CLI, credentials, and protocol are all verified good outside Buzz:
gemini -p "Reply with exactly one word: working" with the same API key → returns working- ACP handshake works: piping
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{}}} into gemini --acp returns a valid result advertising protocolVersion: 1, agentInfo.name: "gemini-cli", and authMethods including gemini-api-key
- Buzz's own model dropdown successfully lists live Gemini models for this harness (so Buzz can authenticate to the provider)
- No auth/credit/config errors in the agent log — the log is simply empty after startup
- Persisted across: agent restart, "Save changes" redeploy, killing the orphaned worker PID, and a full app restart
Additional context
Also worth noting: when the agent's worker process becomes orphaned, "Save changes" and the profile restart button silently no-op — the worker keeps running with stale config and the log stays frozen. Killing the PID from agents/agent-pids/ was the only way to force a genuine respawn. That made this bug considerably harder to diagnose, since every fix appeared to apply but changed nothing.
Environment
- OS: Windows 11
- Buzz version: 0.5.2 (Windows, unsigned alpha build)
- gemini-cli: 0.53.1, invoked as
gemini --acp
- Working comparison harnesses:
@agentclientprotocol/codex-acp 1.1.7, @agentclientprotocol/claude-agent-acp 0.64.0
Describe the bug
An agent on a custom ACP harness that reports
steering_supported=falseis subscribed to a channel and shown as online, but never receives any mentions. No error surfaces anywhere — the agent simply stays silent forever. Agents whose harness reportssteering_supported=truereceive mentions in the same channel normally.I hit this with a custom harness wrapping
gemini-cli(gemini --acp, v0.53.1). The Gemini CLI itself is fine — see "Ruled out" below.Evidence
Three agents, same community, all subscribed to the same channel, all
subscribe=Mentions:steering_supported@agentclientprotocol/codex-acptrue@agentclientprotocol/claude-agent-acptruegemini-cli(custom harness)falseThe two working agents log delivery activity on every mention:
The Gemini agent, in the same channel over the same period, logs nothing at all after startup:
Every mention delivery path that appears in the working agents' logs goes through
steer. That suggests mention delivery is gated on steering support, and harnesses that reportsteering_supported=falsefall through with no fallback and no warning.To reproduce
gemini --acp, gemini-cli 0.53.1).@mentionthe agent in that channel.Expected behavior
Mentions should be delivered to agents regardless of steering support — steering is an optimisation for interrupting/updating an in-flight turn, not a prerequisite for starting one. Failing that, Buzz should surface a clear readiness error (like it does for missing adapters/logins) rather than showing the agent as online and healthy.
Ruled out — the CLI, credentials, and protocol are all verified good outside Buzz:
gemini -p "Reply with exactly one word: working"with the same API key → returnsworking{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{}}}intogemini --acpreturns a valid result advertisingprotocolVersion: 1,agentInfo.name: "gemini-cli", andauthMethodsincludinggemini-api-keyAdditional context
Also worth noting: when the agent's worker process becomes orphaned, "Save changes" and the profile restart button silently no-op — the worker keeps running with stale config and the log stays frozen. Killing the PID from
agents/agent-pids/was the only way to force a genuine respawn. That made this bug considerably harder to diagnose, since every fix appeared to apply but changed nothing.Environment
gemini --acp@agentclientprotocol/codex-acp1.1.7,@agentclientprotocol/claude-agent-acp0.64.0