Buzz Desktop 0.5.2: agent_args reset to [] and missing_binary setup payload error prevents OpenCode ACP integration #3824

Activity

1. iroiro147 commented on Jul 31, 2026

   

   iroiro147

   on Jul 31, 2026

   Contributor

   More actions

   Cross-reference for reviewers — both halves of this issue appear to be covered by open PRs, so likely no independent fix needed here.

   Bug 1 (agent_args silently [] → interactive mode → 60s timeout): Root cause is opencode missing from the default_agent_args identity table used by the Tauri spawn path (desktop/src-tauri/src/managed_agents/discovery.rs). Open PR #3706 already adds exactly "opencode" => Some(vec!["acp"]) to that table — the same fix class as #3793 (omp) / #3458 (grok). That preserves the user's "no args → acp" intent without needing the wrapper-script workaround.

   Bug 2 (missing_binary unknown variant): Buzz Desktop serializes Requirement::MissingBinary into BUZZ_ACP_SETUP_PAYLOAD, but buzz-acp v0.5.2's SetupPayload has no matching variant. Open PR #3598 adds the missing_binary variant + rendering to crates/buzz-acp/src/setup_mode.rs directly.

   Suggest holding this issue for #3706 + #3598 to land rather than duplicating effort. cc @m-faizan-tariq
2. jimparkins commented on Aug 3, 2026

   

   jimparkins

   on Aug 3, 2026

   More actions

   Confirming this on Oh My Pi (omp) as well — same failure, same 60s timeout — and I think I can pin the root cause, which neither this issue nor #3457 quite locates.

   Environment: Buzz Desktop 0.5.x, macOS arm64, omp at /opt/homebrew/bin/omp, relay = a hosted community.

   Symptom (identical to yours):

   agent_cmd=/opt/homebrew/bin/omp          ← no arguments
   Reading prompt from piped stdin (waiting for EOF; ctrl+c to abort)…
   Still starting after 10s — phase: readPipedInput
   ...
   [Uncaught Exception] Error: EPIPE: broken pipe, write
   ERROR buzz_acp: agent initialize failed: Request timeout — agent did not respond within 60s
   

   The EPIPE is just the aftermath — omp writing to a pipe buzz-acp has already dropped after giving up.

   Root cause

   Buzz holds the correct value in one place and never consults it in the other.

   desktop/src-tauri/src/managed_agents/discovery/presets.rs — correct:

   PresetHarness { id: "omp", label: "Oh My Pi", command: "omp", args: &["acp"], … }

   desktop/src-tauri/src/managed_agents/discovery.rs:466 — the fallback that actually runs:

   fn default_agent_args(command: &str) -> Option<Vec<String>> {
       match normalize_command_identity(command).as_str() {
           "goose" => Some(vec!["acp".to_string()]),
           "codex" | "codex-acp" | "claude-agent-acp" | "claude-code-acp"
           | "claude-code" | "claudecode" | "buzz-agent" => Some(Vec::new()),
           _ => None,          // ← omp, opencode, grok all land here
       }
   }

   So any preset outside goose / the codex-claude family gets no args whenever agent_args is empty, and launches in interactive mode instead of ACP. That covers this issue (OpenCode), #3457 (Grok Build) and Oh My Pi — one bug, three reports.

   A fix might be to have default_agent_args() fall back to the PresetHarness.args for the matching preset, rather than maintaining a second hardcoded list that has to be kept in sync.

   Workaround that worked here

   Setting agent_args explicitly in ~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json (quit Buzz first — it rewrites on exit):

   "agent_command_override": "omp",
   "agent_args": ["acp"]

   After relaunch the handshake completes:

   INFO buzz_acp: agent initialized agent=7 name="oh-my-pi" steering_supported=false
   

   This is safe for omp specifically because default_agent_args("omp") returns None, so normalize_agent_args returns the stored value verbatim. Note the branch at discovery.rs:489 — a lone "acp" is stripped when default_args is Some(vec![]), so the same workaround would not hold for the codex/claude family.

   FWIW I have not yet seen the reset-to-[] behaviour you describe — the value has survived a relaunch and ~25 minutes of use here — so that part may be narrower than the missing-args bug itself.

   Also worth noting: BUZZ_ACP_AGENT_ARGS cannot be used as a workaround via env_vars, since it is on the reserved list in managed_agents/env_vars.rs (code-execution surface) and is rejected on save.
3. jimparkins commented on Aug 3, 2026

   

   jimparkins

   on Aug 3, 2026

   More actions

   Still reproduces on Buzz Desktop 0.5.4 (released 2026-08-03). Verified with a controlled test — one agent changed, two left as controls, same machine, same relaunch:

   Agent	agent_args in managed-agents.json	Resulting agent_cmd
   Honey	[]	/opt/homebrew/bin/omp — no acp
   Fizz	["acp"]	/opt/homebrew/bin/omp acp
   Bumble	["acp"]	/opt/homebrew/bin/omp acp

   So the missing-args behaviour is entirely down to agent_args being empty; nothing in 0.5.4 supplies the preset's declared args as a fallback.

   I had hoped #3580 ("fix(config-bridge): add harness-definition env tier", shipped in 0.5.4) might cover this, since a harness-definition tier sounds like the right home for a harness's default args. It does not — that change is about config-resolution precedence and origin reporting, and does not make default_agent_args() consult PresetHarness.args.

   desktop/src-tauri/src/managed_agents/discovery.rs is unchanged in the relevant part: default_agent_args() still matches only "goose" and the codex/claude family, returning None for everything else — while discovery/presets.rs continues to declare args: &["acp"] for omp, opencode, Cursor and others.

   One extra data point for the reset-to-[] half of this report: my manually-set agent_args: ["acp"] survived the 0.5.3 → 0.5.4 in-place update and several app relaunches. So on this machine the values persist once set; the bug I can reproduce reliably is purely the missing default.
4. hbdevv commented on Aug 7, 2026

   

   hbdevv

   on Aug 7, 2026

   More actions

   Confirmation on Desktop 0.5.6 (macOS arm64)

   This issue still occurs on Buzz Desktop v0.5.6 with Grok-backed managed agents (Fizz / similar), not only OpenCode on 0.5.2.

   Symptom. After stop/restart (or an app update), agents fail immediately with:

   malformed BUZZ_ACP_SETUP_PAYLOAD: unknown variant missing_binary, expected one of normalized_field, env_key, cli_login, cli_config_invalid, git_bash

   Cause (observed). Desktop emits a setup requirement with surface: "missing_binary", but the bundled buzz-acp binary does not accept that variant, so setup mode exits instead of handling the condition. This is easy to trigger when the CLI is not on Desktop’s probe paths (e.g. ~/.local/bin, Homebrew) and the agent override is a bare command name such as grok.

   Workaround.

   1. Ensure the CLI is discoverable (e.g. ln -sfn "$HOME/.grok/bin/grok" "$HOME/.local/bin/grok").
   2. In managed-agents.json, set agent_command_override (and provider_binary_path if used) to an absolute path; keep parallelism modest (e.g. 3).
   3. For Grok, prefer agent_args: ["--always-approve","agent","stdio"] (Desktop may still reset agent_args to []; a non-TTY shim helps).

   After recovery, logs should show a normal buzz-acp starting line with an absolute agent_cmd and presence set to online, without the missing_binary parse error.

   Request. Align Desktop and buzz-acp on the setup-payload schema (accept or stop emitting missing_binary), and avoid hard-failing setup mode when readiness checks fail.