Agent responses generated correctly but never published to channel/thread — reproducible across models (Qwen3VL-8B, Gemma-12B, Qwen3.6-35B) and harnesses (OpenCode, Buzz Agent), self-hosted single-tenant relay

[guilherme-fish-dev]

Describe the bug
Agents generate correct, complete responses — visible in the agent's own Activity/Thinking panel — but the response never reaches the channel/thread it was mentioned in (or, in an earlier variant before a partial mitigation, only a truncated/garbled fragment lands there). This has now been reproduced with:

• 3 different local models behind an OpenAI-compatible llama-server (llama.cpp) backend: Qwen3VL-8B-Instruct, Gemma-4-12B-it, and Qwen3.6-35B-A3B — response quality varies a lot between them, but the "never published" symptom is identical across all three.
• 2 different agent harnesses: the OpenCode ACP adapter and the native Buzz Agent harness.

This strongly suggests the bug is in Buzz's publish pipeline itself, not in model capability, prompt content, or harness choice. Related: #4709, #4352, #5046 all describe the same "generated but not delivered" pattern.

Steps to reproduce

1. Self-host the relay via deploy/compose/ (Docker Compose bundle), BUZZ_REQUIRE_RELAY_MEMBERSHIP=false, BUZZ_REQUIRE_AUTH_TOKEN=false, single tenant (no multi-tenancy involved).
2. Point any local OpenAI-compatible model (OPENAI_COMPAT_BASE_URL at a local llama-server) as the agent's LLM provider, via either the OpenCode or native Buzz Agent harness.
3. Create an agent in a channel, mention it.
4. Observe: full response appears in the agent's Activity/Thinking panel; the channel/thread stays empty (no reply visible), even though the composer shows the message was "sent" (checkmark) and the agent shows as processing/online.

Expected behavior
The full response generated by the agent should be published to the channel/thread it was mentioned in.

What we found while investigating (may help narrow it down)

1. With the OpenCode harness, the buzz-acp harness log never showed any line about receiving a mention or attempting to publish, despite agent_pool_ready and successful channel subscription — across multi-hour windows with zero other log activity.
2. With the native Buzz Agent harness, first attempt failed outright with Turn error · error: Community access denied this agent — check its community membership, even with BUZZ_REQUIRE_RELAY_MEMBERSHIP=false at the relay level. Running buzz-admin add-member <agent-pubkey> resolved the outright denial.
3. After the membership fix, responses started reaching the channel sometimes, but a newly-created channel (agent added via the "Create agent"/"Add people" UI at channel-creation time) again failed to deliver until the agent's harness was manually restarted — suggesting channel discovery only happens reliably at harness startup, not on live membership-notification events, matching the "membership changes do not re-resolve on a running harness" finding from a comment on a related issue.
4. Even after the restart-fixes-it pattern worked once, it did not hold reliably across new channels/sessions — the same "generated in Activity, never published" symptom recurred in a brand-new channel with a freshly restarted harness and a completely different (larger, presumably more capable) model, which rules out model quality as a factor.
5. Separately (a real but distinct bug worth splitting out if useful): when an agent's tool-calling loop repeatedly fails a file edit (wrong old_str match) with a small local model, nothing caps the retry loop — context grows every retry until it exceeds the model's context window, at which point the harness enters an unrecoverable retry-with-backoff loop that can never succeed (context is already over the limit) but keeps retrying with exponentially growing delays forever.

Version and platform

• Buzz: built from source, main branch, self-hosted via deploy/compose/
• OS: Windows 11
• Harnesses tested: OpenCode (buzz-acp + opencode acp), native Buzz Agent (buzz-agent.exe)
• Models tested: Qwen3VL-8B-Instruct-Q4_K_M, Gemma-4-12B-it-Q4_K_M, Qwen3.6-35B-A3B-UD-Q4_K_M — all via local llama-server

Logs / additional context
Happy to provide full buzz-acp/buzz-agent harness logs and relay logs (secrets redacted) on request — have several captures across the different failure variants described above.

[kiranmagic7]

Guilherme, the Activity-without-channel slice is already tracked most directly in #2698. On current main (119a848), AcpClient::handle_session_update logs agent_message_chunk text but has no publish call. The two relevant implementation shapes are #3883, which keeps a fallback armed until an explicit send is confirmed, and #5420, which makes harness-owned publication opt-in. I would compare this report against those instead of starting a third delivery patch.

The membership denial/new-channel restart behavior and the uncapped edit loop should be split out. They occur at different boundaries, and publishing ACP output would not prove either one fixed.

For the delivery slice, the regression contract should cover one accepted kind:9 on a normal EndTurn, correct h/thread/author p tags derived from the accepted trigger, no duplicate after a successful explicit send, and no partial reply after cancellation, timeout, a turn limit, or heartbeat.

[guilherme-fish-dev]

Thanks @kiranmagic7 — that's a very precise diagnosis and matches what we were seeing exactly (Activity/Thinking panel always showed the full generated response; channel/thread stayed empty). Good to know the AcpClient::handle_session_update → missing publish call is already tracked at #2698, with #3883 and #5420 as the candidate delivery-shape fixes.

Per your suggestion, I'll close this one in favor of #2698 for the core delivery gap, and I've split the membership-denial/new-channel-restart behavior into its own focused report (#5446 was conflating a few distinct things). Not filing anything further on the uncapped retry loop — on reflection that one's plausibly just small-model imprecision at exact-match file edits rather than a Buzz-side bug, so I don't think it's worth a separate report.