Buzz Desktop ignores a managed agent's configured mcp_command — custom MCP servers never attach

[budzeg]

Repo: block/buzz · App version: 0.5.5 · Platform: macOS
Severity: High — blocks every managed agent from using any MCP other than the bundled buzz-dev-mcp.

Summary

A managed agent's configured MCP command (managed-agents.json → entry mcp_command) is never forwarded to buzz-acp. On every agent start the launcher spawns buzz-acp with the bundled sidecar:

mcp_cmd=/Applications/Buzz.app/Contents/MacOS/buzz-dev-mcp

so agents only ever get the bundled buzz-dev-mcp tools and can never attach a custom stdio MCP. Setting the env override env_vars.BUZZ_ACP_MCP_COMMAND on the agent does not help either (see root cause).

Impact

Every managed agent is limited to the bundled buzz-dev-mcp, so the per-agent mcp_command field has no effect. Any deployment that relies on a custom MCP (e.g. a multiplexer that adds extra tool servers) cannot attach it. Observed across many agent starts across all agents: mcp_cmd is always the bundled buzz-dev-mcp, never the configured value.

Reproduction

1. In ~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json, set an agent entry's mcp_command to an absolute path to any custom stdio MCP, e.g. /opt/example/my-mcp.
2. Fully quit and relaunch Buzz Desktop (not just restart the agent).
3. Inspect the agent's acp log under ~/Library/Application Support/xyz.block.buzz.app/agents/logs/.

Expected: buzz-acp starting: … mcp_cmd=/opt/example/my-mcp … and the MCP handshake reports the custom server (server_info name = the custom server's name).
Actual: buzz-acp starting: … mcp_cmd=/Applications/Buzz.app/Contents/MacOS/buzz-dev-mcp … and serve_inner … server_info: Implementation { name: "buzz-dev-mcp", … }.

Also reproducible by setting only env_vars.BUZZ_ACP_MCP_COMMAND=/opt/example/my-mcp (no mcp_command) and relaunching — the env value is still overridden by the launcher's explicit flag.

Root cause

• buzz-acp --mcp-command is [env: BUZZ_ACP_MCP_COMMAND] [default: ""] (confirmed via buzz-acp --help).
• The desktop launcher spawns buzz-acp with an explicit --mcp-command <bundled buzz-dev-mcp> (it resolves the bundled Tauri sidecar binaries/buzz-dev-mcp), rather than forwarding the per-agent mcp_command from the managed-agent record.
• Because an explicit clap CLI flag wins over the env var, even setting env_vars.BUZZ_ACP_MCP_COMMAND on the agent cannot override it. So neither the config field nor the env override takes effect.

Suggested fix (acp-spawn path of the desktop launcher / Tauri backend)

When building the buzz-acp argv for a managed agent, use the agent's configured mcp_command when non-empty, falling back to the bundled sidecar only when it is empty:

// pseudo
let mcp_cmd = if !agent.mcp_command.trim().is_empty() {
    agent.mcp_command.clone()            // honor per-agent override (absolute path)
} else {
    bundled_sidecar_path("buzz-dev-mcp") // current default
};
cmd.arg("--mcp-command").arg(&mcp_cmd);

Equivalently: pass the configured mcp_command as the flag when set, OR stop passing an explicit --mcp-command when the agent supplies BUZZ_ACP_MCP_COMMAND so the env override can win. The launcher already forwards agent env_vars to the child process (other custom env vars set on an agent do reach the MCP), so the env plumbing works — only the explicit flag needs to defer to config.

Why this is the right shape (no acp change needed)

buzz-acp intentionally accepts a single --mcp-command. The supported pattern for "bundled dev tools + extra MCPs" is a stdio multiplexer that itself spawns buzz-dev-mcp plus the extra servers behind one stdio server. That pattern works today when the multiplexer is driven directly — the only missing piece is the launcher honoring mcp_command so the multiplexer becomes the agent's attached server. Once it does, agents keep all bundled dev tools AND gain the extra tools, with no acp or protocol change.

Workaround until fixed

None from config/env on the current build. Agents can still invoke a custom MCP indirectly by launching it as a subprocess from within a shell tool call, but its tools will not appear in the attached tool surface until the launcher fix ships.