buzz-acp: OpenCode-backed agents hang/timeout — session/set_config_option sends Claude-only permission mode values OpenCode rejects

[nonsleepr]

Summary

buzz-acp agents backed by agent_command_override: "opencode" reliably hang and time out during initialization ("Request timeout — agent did not respond within 60s") on every model, on Linux. Root cause: --permission-mode sends a session/set_config_option call with a value from buzz-acp's hardcoded Claude-flavored enum (default/accept-edits/bypass-permissions/dont-ask/plan), but OpenCode's ACP mode config option only accepts build/plan. OpenCode correctly returns a JSON-RPC error for the unrecognized value, but buzz-acp appears to hang waiting rather than handling the error (it only gracefully falls back for "Method not found", e.g. from claude-code-acp, which doesn't implement session/set_config_option at all).

Reproduction (direct ACP round-trip against opencode acp, no buzz involved)

opencode --version   # 1.18.9

// 1. initialize -> ok
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{}}}

// 2. session/new -> ok, returns configOptions with a "mode" option whose only
//    valid values are "build" and "plan"
{"jsonrpc":"2.0","id":2,"method":"session/new","params":{"cwd":"/home/me","mcpServers":[]}}

// 3. session/set_config_option with buzz-acp's default value -> hard error
{"jsonrpc":"2.0","id":3,"method":"session/set_config_option","params":{"sessionId":"<sid>","configId":"mode","value":"bypassPermissions"}}

Response to (3):

{"jsonrpc":"2.0","id":3,"error":{"code":-32602,"message":"Invalid params: mode not found: bypassPermissions","data":{"mode":"bypassPermissions"}}}

The same happens for every other PermissionMode variant buzz-acp can send (default, accept-edits, dont-ask) since none map to OpenCode's build/plan vocabulary — confirmed by inspecting session/new's returned configOptions for the mode category. There is currently no BUZZ_ACP_PERMISSION_MODE value that works with an OpenCode-backed agent.

Observed in buzz-desktop logs

buzz-acp starting: ... agent_cmd=/home/user/.bun/bin/opencode ... permission_mode=bypassPermissions ...
ERROR buzz_acp: agent timed out during init (60s) agent=0
ERROR buzz_acp: agent initialize failed: Request timeout — agent did not respond within 60s agent=1
ERROR buzz_acp: agent initialize failed: Request timeout — agent did not respond within 60s agent=2

No corresponding opencode log file is ever created for the failed instances (~/.local/share/opencode/log/), and the buzz session logger's per-session .md file stays stuck at "Status: Active" with zero further content — consistent with the agent process being stuck waiting on the session/set_config_option response rather than crashing.

This reproduces on every model (spark/glm-5.2, spark/qwen36-35b-a3b) and is unrelated to auth/network — a bare session/new + session/prompt round trip against the same opencode acp process (skipping the session/set_config_option call) completes in a few seconds.

Environment

• Buzz Desktop 0.5.2, Linux x86_64
• OpenCode 1.18.9
• agent_command_override: "opencode" on a managed agent (per ~/.local/share/xyz.block.buzz.app/agents/managed-agents.json)

Suggested fix

Either:

1. Treat any non-"Method not found" error from session/set_config_option as non-fatal (log and continue without the mode override), the same way "Method not found" is already handled, or
2. Query session/new's returned configOptions for the mode category's valid options and only attempt session/set_config_option if the configured PermissionMode's wire value is actually in that list, or
3. Add an adapter-specific permission-mode mapping (similar in spirit to buzz-acp: no way to select Claude Code's auto permission mode — adapter advertises it, PermissionMode omits it #2884's request for a Claude auto variant) so OpenCode's build/plan modes can be targeted directly instead of assuming Claude's vocabulary.

Related but distinct: #3660 reports the same overall symptom ("Opencode acp not working" / 60s init timeout) but attributes it on Windows to a missing acp subcommand argument. On Linux, buzz-acp's default --agent-args acp is applied correctly (confirmed the spawned command is opencode acp), so that isn't the cause here — this is a distinct bug in the session/set_config_option error-handling path.

[bradhallett]

A fix is up in #3804. It resolves this by deriving the per-runtime launch args from the single-source PRESET_HARNESSES table in resolve_effective_harness_descriptor, so an agent pinned to this runtime (e.g. via agent_command_override with no runtime id) launches its ACP/stdio mode instead of the bare command/TUI that timed out at initialize.