Desktop goose ACP agents silent or flaky with custom OpenAI-compatible provider (hosted models) #4233

Activity

1. extraknown-alec commented on Aug 2, 2026

   

   extraknown-alec

   on Aug 2, 2026

   More actions

   I'm far less technically proficient than this original poster but I believe I'm having the same issue. Just spent all day trying to get an oMLX instance running local models (does so reliably the last 3 weeks) to return text to the Buzz discussion that initiated it.

   Everything works great in Goose Desktop using either the built-in oMLX provider, or creating a custom OpenAI Compatible provider. However when setting up Buzz agents, the best outcome I can muster using either Goose+oMLX provider, or Goose+Custom Provider, is for the agent to (very slowly I'll add) request and reply but the turn never outputs to the chat window. I see it in the Activity view however.

   As I said, it works well in Goose and much faster. No combination of settings, and aggressively wiping Buzz and reinstalling, or even creating a new community works.
2. iroiro147 commented on Aug 2, 2026

   

   iroiro147

   on Aug 2, 2026

   Contributor

   More actions

   Triage note from a fresh read — this is a really good write-up of three distinct failure modes (A=secrets flow, B=content-delivery fallback, C=workspace clobber). They're independent enough that each could land as its own small PR; combining them into one 4-acceptance-criteria PR invites the kind of review deadlock none of us want.

   Suggested split:

   • C (workspace clobber): smallest, most deterministic. Single-point change in resolve_workspace_command (desktop/src-tauri/src/managed_agents/discovery.rs) — add a bool argument or a config knob that, when acp_command is an absolute path that already exists on disk, skips the workspace-target resolution entirely. Acceptable behavior on tauri dev/packaged builds. ~5 LOC + tests.
   • A (custom-provider secrets): mostly docs + one harness tweak. Add a section to docs/agents/goose.md covering GOOSE_DISABLE_KEYRING=1 + provider-specific env names for GUI spawns, and (optionally) warn in the agent add-wizard when GOOSE_PROVIDER=custom_* is set without GOOSE_DISABLE_KEYRING. ~20 LOC docs + optional warn.
   • B (content-delivery fallback): the biggest behavior change. The KISS deterministic version (post assistant text once if no successful publish tool) is probably right, but it interacts with PUBLISH ONCE guarantees, typing indicator state, and undo/redo in the timeline. Needs a design conversation, not a one-PR commit.

   I have capacity to ship C right now — it doesn't gate on A or B having a chosen direction. Opening a tiny PR for C so the obvious dev-workflow footgun is fixed while the longer conversations happen.

   ❤️React with ❤️1Reacted by Frozen Packet
3. coldcanuk commented on Aug 2, 2026

   

   coldcanuk

   on Aug 2, 2026

   Author

   More actions

   Status update (coldcanuk / actvite)

   We opened and maintained a fork with the worktree + commits for Layer B (content-delivery fallback) and S1.1 once-publish-per-trigger (multi-step double/triple-post guard).

   Fork / worktree / commits

   Item	Value
   Fork	https://github.com/coldcanuk/buzz
   Worktree (host)	/opt/repo/worktrees/wt-acp-s1-auto-publish-20260801
   Branches	fizz/acp-s1-auto-publish and fizz/acp-once-publish-stop (same tip)
   HEAD	1d0708a9a
   Fork main	Fast-forwarded to the same tip for local deploy tracking

   Commits on the branch (rebased onto current block/buzz main):

   1. bca8bab78 — fix(acp): deliver plain-text replies when the model skips the send tool
   2. f68a1d7ae — fix(acp): confirm message delivery from tool outcome, not input text
   3. f5e5ecb89 — feat(acp): S1 detect MCP buzz_messages_send tool names
   4. 1d0708a9a — feat(acp): once-publish-per-trigger stop after first confirmed send

   Pull request (Layer B + S1.1)

   → #4191

   Cites this issue. Scope is Layer B / B′ only (publish contract + once-publish stop). Layer A (custom-provider secrets / GOOSE_DISABLE_KEYRING) remains out of that PR (docs/ops follow-up).

   Related work already in flight

   • Layer C (workspace target/debug clobber) — thank you @iroiro147 for the triage split and fix(desktop): prefer user-installed binaries over workspace target for bare commands #4284. That is complementary; our feat(acp): S1 content-delivery fallback + once-publish-per-trigger #4191 does not claim C.
   • Community report from @extraknown-alec (oMLX / local models, Activity has text but channel stays silent) matches Layer B class; S1 content-delivery is intended to cover that path once the fixed harness is what Desktop actually spawns.

   What this does not fix alone

   • Custom provider Provider not set without Desktop env (GOOSE_DISABLE_KEYRING=1 + secrets) — Layer A.
   • Dev bare-command clobber after cargo build — Layer C / fix(desktop): prefer user-installed binaries over workspace target for bare commands #4284 + absolute acp_command pin as workaround.

   Happy to iterate on review feedback on #4191.
4. Pep939 commented on Aug 4, 2026

   

   Pep939

   on Aug 4, 2026

   More actions

   Independent reproduction of this failure class on the first-party buzz-agent runtime — not goose — which suggests the gap is in the harness publish path rather than in any particular third-party ACP implementation.

   Environment

   Piece	Setup
   Host	Buzz Desktop 0.5.2 (release AppImage, not tauri dev)
   Relay	Hosted wss://<name>.communities.buzz.xyz (also reproduced against a self-hosted relay)
   Runtime	buzz-agent via buzz-acp harness
   Provider	openai-compat → Ollama on 127.0.0.1:11434
   Model	ornith:9b (local, 6.4 GB, fully GPU-resident)
   Access	respond_to default; owner @mention in an open channel

   The controlled comparison

   One message @-mentioning three agents at once, same channel, same instant:

   Agent	Runtime	Result
   A	claude-agent-acp	posts a kind:9 thread reply ✅
   B	codex-acp	posts a kind:9 thread reply ✅
   C	buzz-agent + local Ollama	no channel event ❌

   Because the three share one relay, one channel, one prompt and one moment, relay/channel/threading and the desktop's thread-render path are all controlled for — the two cloud runtimes' replies render normally in that same thread. The only variable is the runtime + local provider, matching this issue's class.

   What is ruled out

   • Not the model returning empty text. Queried the same endpoint directly:

     curl -s http://127.0.0.1:11434/v1/chat/completions -d '{"model":"ornith:9b","messages":[{"role":"user","content":"Say exactly: hello from ornith"}]}'
     → keys: ['role', 'content', 'reasoning']
       content:   'Hello from Ornith!'
       reasoning: 'The user wants me to say "hello from ornith"...'
       finish_reason: stop
     

     content is populated and distinct from reasoning, so crates/buzz-agent/src/agent.rs:212 (response.text → agent_message_chunk) has real text to emit. The text does reach the desktop — it renders in the agent's observed session / activity pane. It just never becomes a channel event.

   • Not inference failure. Ollama logs a clean turn every time, e.g.
     [GIN] 200 | 9.701881956s | POST "/v1/chat/completions" with no errors, timed to the @mention.

   • Not the thread-render bug in docs/welcome-kickoff-silent-failures.md §4 — that hides replies that exist; here the sibling agents' replies render fine in the same open thread.

   • Not buzz PATH shadowing (buzz on PATH shadows the real headless CLI with the GUI-launch wrapper — silent no-op on messages send for ACP agents #3471). which buzz resolves to a real compiled CLI binary, not the GUI launcher wrapper.

   Harness signature

   Agent log at ~/.local/share/xyz.block.buzz.app/agents/logs/<pubkey>__<hash>.log, immediately after the prompt:

   05:06:37  connected to relay at wss://<redacted>
   05:06:37  discovered 2 channel(s) / subscribed / presence set to online
   05:06:37  buzz_agent: session/set_model: model overridden model_id=ornith:9b
   05:08:16  rmcp::service: input stream terminated
   05:08:16  rmcp::service: serve finished quit_reason=Closed
   05:08:16  buzz_acp: shutting down
   05:08:16  buzz_acp: shutdown: waiting for in-flight prompts
   05:08:16  buzz_acp: presence set to offline
   05:08:16  buzz_acp: buzz-acp stopped
   

   The assistant text was visible in the desktop at 05:06:45 — ~90 s before this shutdown. The same log shows 9 buzz-acp starting lines in a single day for this agent.

   I want to be explicit that I have not established whether that mid-turn shutdown causes the missing publish or is a downstream symptom — it is a signature, not a diagnosis. Flagging it because it lines up with this issue's "turn completion without any publish tool and without harness content-delivery fallback" bullet, and because a harness that tears down while waiting for in-flight prompts is a plausible place for a reply to be dropped.

   Happy to run instrumented builds or pull further logs on this setup if useful — it reproduces on demand.

   👍React with 👍1Reacted by Frozen Packet
5. blabj commented on Aug 16, 2026

   

   blabj

   on Aug 16, 2026

   More actions

   Additional data point: same silent-failure class with custom OpenAI-compatible provider but with an opencode-override agent — root cause appears to be mcp_cmd never being attached

   Setup: Buzz Desktop 0.5.14 (macOS), custom managed agent with agent_command: "buzz-agent" and agent_command_override: "opencode" → harness runs /opt/homebrew/bin/opencode acp, model served through a local LiteLLM proxy (OpenAI-compatible)

   Symptom: Agent produces a complete reply (confirmed in opencode's SQLite session store — finish: "stop", text part present, 14k in / 58 out) but nothing ever renders in the channel. No partial message, no error — exactly the silent failure S1 describes.

   Root cause found — the publish tool is never attached:

   1. Harness startup line (ACP log):

      buzz-acp starting: ... agent_cmd=/opt/homebrew/bin/opencode acp mcp_cmd= idle_timeout=900s ...
      

      mcp_cmd= is empty, even though the agent's managed-agents.json entry declares "mcp_command": "buzz-dev-mcp".

   2. Live process env confirms it — the harness was launched with BUZZ_ACP_MCP_COMMAND= empty, so this isn't a negotiation-time drop; the desktop app never passed the command through for this agent.

   3. Possible contributing factor: opencode's ACP handshake advertises "mcpCapabilities":{"http":true,"sse":true} — no stdio — and buzz-dev-mcp is a stdio command. If capability negotiation is what gates the stdio MCP launch, that would explain the empty mcp_cmd even when the config declares it.

   4. Consequence: the session had zero tool calls (parts are only step-start → text → step-finish), so per the harness contract ("a result… exists only if you published it"), the reply is discarded. 0.5.14 has no fallback to recover it.

   Workaround attempted: added buzz-dev-mcp as a local MCP server in opencode's own config (opencode.json) so the agent would inherit the harness's BUZZ_PRIVATE_KEY/BUZZ_AUTH_TAG/BUZZ_RELAY_URL env — publish tool still didn't fire / still no delivery.

   This seems to be the gap your content-delivery fallback covers — happy to provide full ACP logs, managed-agents.json redacted, or run any debug builds if useful. Also worth noting: with an override agent, the bundled buzz-agent wrapper (which bootstraps MCP) is bypassed entirely, and goose isn't installed on the machine, so the only paths into MCP are the harness's own (empty) mcp_cmd or manual agent-side config.

   👍React with 👍1Reacted by Frozen Packet
6. ochianciprian95 commented on Aug 17, 2026

   

   ochianciprian95

   on Aug 17, 2026

   More actions

   Reproduced on desktop 0.5.14 (macOS, darwin 25.5), goose 1.45.0, with provider openai and secrets resolving correctly, so this failure class is wider than the openai-compat secrets path described above.

   Setup: three managed goose agents, each pointed at a local OpenAI-compatible bridge through agent env vars (OPENAI_HOST=http://127.0.0.1:<port>, OPENAI_API_KEY and OPENAI_COMPAT_API_KEY set to the placeholder the bridge accepts). respond_to=owner-only, parallelism 1, Block-hosted relay.

   On every owner @mention, for all three agents, in a private channel and in a fresh public one:

   1. The agent publishes its ack reaction (:speech_balloon:) to the mention, so the key, the relay connection and event publishing work.
   2. The engine turn completes. The bridge logs the request, and the full final assistant text sits in ~/.local/state/goose/logs/llm_request.0.jsonl marked userVisible. Desktop's per-agent activity feed shows the same final text.
   3. No kind:9 reply reaches the channel, neither top level nor in a thread.
   4. buzz_acp info logs stay frozen after subscribed to channel ...: no error, no agent_returned, nothing. This matches the note above that a frozen log is not a falsifier.

   Two details that may narrow it down:

   • One of the three agents also posts to a channel every morning through a workflow trigger, in the same install, against the same bridge. Those messages arrive. Only the mention path loses the text.
   • Before we switched the provider to openai we hit the -32603 Internal error surfaced as a Codex message; that part matches Goose harness: Buzz injects GOOSE_PROVIDER=openai-compat (invalid), overriding a working Goose config; surfaces as a Codex error #4569 (GOOSE_PROVIDER=openai-compat injection) and went away with the provider change.

   In our traces goose never calls a publish tool during the mention turn; the final text only comes back as ACP turn output. If the harness content-delivery fallback is what should publish it in that case, the fallback does not fire on 0.5.14.
7. iroiro147 commented on Aug 27, 2026

   

   iroiro147

   on Aug 27, 2026

   Contributor

   More actions

   @ochianciprian95 Your reproduction widens this materially and I should have said so sooner — apologies for the week of silence.

   The important part is that you hit it with provider openai and secrets resolving correctly. The earlier reports in this thread all involved the openai-compat secrets path, which made a secrets-resolution bug the natural reading. Three agents failing identically on a Block-hosted relay, with the ack reaction publishing but no message, rules that out: the key, the relay connection and the publish path are all demonstrably working, so whatever drops the reply sits after generation and before the message publish, independent of provider family.

   That is the same failure class @Pep939 reported on the first-party buzz-agent runtime and @blabj on an opencode override — which together point at the harness publish path rather than any one ACP implementation, exactly as @Pep939 argued.

   My open PR here (#4284) addresses the secrets path specifically, so on the evidence you have posted it will not fix your case. I would rather say that plainly than let it look like coverage.

   I am not going to open a second PR at this repository — there are already more open from me than is reasonable for one reviewer, and the harness publish path is a bigger change than I should be adding to that pile uninvited. If a maintainer would rather I did take it, say so and I will.

   One thing that would sharpen the diagnosis if you have the appetite: whether the agent's own runtime shows a completed response (goose keeps one in its session store, as @blabj confirmed for opencode). If the reply exists there but never reaches the channel, that isolates it to publish rather than generation, on a third runtime, and makes the case hard to dismiss.