buzz-acp: one MCP server per agent forces a choice between the shell and any domain server #2899

Activity

1. wolfyy970 commented on Jul 30, 2026

   

   wolfyy970

   on Jul 30, 2026 – with ChatGPT Codex Connector

   More actions

   I found two related paths:

   • build_mcp_servers returns zero or one server, although session_new_full accepts Vec<McpServer>.
   • Desktop derives the companion MCP only from KNOWN_ACP_RUNTIMES. Preset harnesses such as omp and hermes-acp therefore receive an empty BUZZ_ACP_MCP_COMMAND. [Bug] Custom/BYOH ACP harness receives no authenticated Buzz reply tool, so completed turns cannot post #3385 confirms the Hermes reply failure.

   PR #1785 implemented structured configuration and layering, but was limited to buzz-agent and closed for inactivity. My analytics MCP also needs arguments and environment variables, so repeatable command strings alone would not cover it.

   Would maintainers prefer a small harness PR that accepts a structured server list and passes it through ACP, followed by a separate Desktop configuration PR based on #1785?
2. MohsinHashmi-DataInn commented on Jul 31, 2026

   

   MohsinHashmi-DataInn

   on Jul 31, 2026

   More actions

   Confirming this from the Buzz Desktop side, and adding a case that I think is narrower than the one described — in case it's useful when shaping the fix.

   Your diagnosis matches exactly what I hit building a pack for a remote MCP server: buzz pack inspect cheerfully reports MCP servers: 1 while the agent receives none. The persona layer parses, merges and validates; nothing downstream reads it.

   Through Desktop with the claude runtime there is no slot at all — not one.

   Against 63496cc1:

   • desktop/src-tauri/src/managed_agents/runtime.rs:527-529 derives the value from the runtime registry constant, never from the agent record:

     let effective_mcp_command = known_acp_runtime(effective_command)
         .and_then(|r| r.mcp_command)
         .unwrap_or("");

   • desktop/src-tauri/src/managed_agents/discovery.rs:113 — the claude entry is hard-coded mcp_command: None, where codex gets Some("buzz-dev-mcp").

   • desktop/src-tauri/src/managed_agents/env_vars.rs:73 — BUZZ_ACP_MCP_COMMAND is in RESERVED_ENV_KEYS, so the Edit-agent Environment variables field can't supply it either. That looks deliberate (code-execution surface) and I'm not suggesting it change.

   Empirically: setting mcp_command on the agent record in managed-agents.json and restarting leaves the spawned harness with BUZZ_ACP_MCP_COMMAND= empty, and build_mcp_servers() returns vec![].

   So making --mcp-command repeatable would fix the either/or for runtimes that already have a slot — buzz-agent, codex — but a Desktop user on the claude runtime would go from zero to zero. Worth knowing before the harness-level fix is called done.

   That's an argument for the persona/runtime option you offered as the alternative: plumbing PersonaConfig.mcp_servers through would cover both cases at once, since the parsing and merging already exist. The harness change would still be worth having on its own — it just wouldn't close this particular gap.

   Happy to file the Claude-runtime piece as its own issue if you'd rather keep this one focused on the harness. Context: I was attaching a remote Streamable HTTP MCP server to a Desktop agent, which also needs an stdio bridge since McpServerConfig carries no url/transport — but that's a separate matter and I don't want to widen this thread.
3. xerg616 commented on Aug 5, 2026

   

   xerg616

   on Aug 5, 2026

   More actions

   Ran into this same limitation today, plus found a workaround worth sharing.

   Setup: Buzz 0.5.3 (alpha, Windows), agent harness "Codex" (the built-in one, softland-buzz-codex-acp.exe), agent already using buzz-dev-mcp to respond in-channel. Tried adding a second local MCP server (a Python/stdio server, mcp[cli]==1.28.1) via SOFTLAND_BUZZ_MCP_COMMAND pointed straight at the .exe (no .cmd wrapper, args: [], env: {}) — the pattern this thread's append_server mechanism expects.

   What happened: the agent started fine and the injected server showed up in the session, but every call into it (tools/call, tools/list, even resources/subscribe) failed with a pydantic validation error on protocolVersion, something like:
   protocolVersion
   Input should be a valid literal ... input_value=2, input_type=int
   For further information visit https://errors.pydantic.dev/2.13/v/literal_error

   repeated across every request-type variant in the union (CallToolRequest, ListToolsRequest, SubscribeRequest, UnsubscribeRequest, even newer GetTaskRequest/GetTaskPayloadRequest members that aren't part of MCP 1.x at all). Looks like the handshake between the bridge and the second injected server is sending/expecting a protocolVersion shape that doesn't match what a standard MCP 1.28.1 stdio server declares — separate from the "one --mcp-command" limit itself, but it surfaces from the same code path (append_server), so possibly related.

   Workaround that actually worked: skip the bridge's injection mechanism entirely and add the second server directly to the underlying Codex CLI's own config.toml:

   [mcp_servers.softland]
   command = 'C:\path\to\your\server.exe'
   args = []

   right alongside the existing [mcp_servers.node_repl]/[mcp_servers.codegraph] entries Buzz already writes there. Restarted the agent and it picked up all three MCP servers correctly (confirmed both in the Runtime panel — codegraph, node_repl, softland all mcp enabled — and by actually invoking a tool from the new server successfully in chat).

   So it seems Codex itself has no problem with >1 mcp_servers entry — the constraint is specifically in how the Buzz↔Codex bridge injects servers via env var (single command, and whatever it does for the handshake trips the newer request-type validation). Wondering if the fix here could be: instead of (or in addition to) SOFTLAND_BUZZ_MCP_COMMAND/--mcp-command, have the bridge just write additional entries into Codex's config.toml the same way it already does for its own built-in servers — that path clearly works today.

   Happy to share the full harness log if useful.
4. last-million

   added a commit that references this issue on Aug 31, 2026

   mcp: support OpenClaw and Hermes; deliberately not Buzz

   ...

   87c9db9
5. last-million

   added a commit that references this issue on Sep 11, 2026

   mcp: support OpenClaw and Hermes; deliberately not Buzz

   ...

   6bd8fdc