You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a desktop agent runs through a tier-2 preset (omp, hermes) or a custom harness, the desktop app never passes an MCP server to the runtime: BUZZ_ACP_MCP_COMMAND is derived only from known_acp_runtime (goose/claude/codex/buzz-agent), so it is always empty for omp/hermes/custom runtimes, and there is no other injection channel. The same MCP config works fine in omp/goose/codex/claude-code/opencode directly: ACP v1 natively defines stdio/http/sse MCP servers (agentclientprotocol/agent-client-protocol, schema/v1/schema.json), all accept client-injected mcpServers, and omp declares http+sse capability in initialize — so this is a Buzz-specific gap.
Use case: A user runs open-connector (streamable HTTP MCP with Bearer auth) against Notion. It works in omp's interactive sessions, but cannot reach a Buzz agent running on omp — we had to bridge stdio→HTTP ourselves.
desktop/src-tauri/src/managed_agents/runtime.rs:527-529 (+ 294-298, 466-469): MCP command derived only via known_acp_runtime(effective_command); comment: "pure derivations of the command… rather than the frozen record snapshot"
desktop/src-tauri/src/commands/agent_models.rs:884-888: "the per-record field is never read by the runtime"; types.rs:258-262 "Never read at spawn"; runtime_metadata.rs:9-10 "Vestigial"
desktop/src-tauri/src/managed_agents/custom_harnesses.rs:49-75: HarnessDefinition has no mcp_command; definition env filtered against RESERVED_ENV_KEYS (env_vars.rs:73 includes BUZZ_ACP_MCP_COMMAND), and validate_user_env_keys rejects on save
discovery/presets.rs:104-112: omp is a tier-2 preset, but KNOWN_ACP_RUNTIMES (discovery.rs:75-180) has only goose/claude/codex/buzz-agent → known_acp_runtime("omp") = None
crates/buzz-acp/src/config.rs:261 → lib.rs:4280: single stdio server from BUZZ_ACP_MCP_COMMAND
Proposal:
Wire the structured MCP config (buzz-acp: add structured MCP server configuration #4164's BUZZ_ACP_MCP_CONFIG) into the desktop spawn path, for preset and custom runtimes alike. When BUZZ_ACP_MCP_CONFIG is absent, keep the existing known_acp_runtime-derived command as the fallback so default behavior is unchanged. The managed-agents reconciler (migration.rs:975/1220) must recognize the new config source, or startup will rewrite managed-agents.json from the directory table and clobber the new channel.
When feat(acp): support remote HTTP MCP servers #4271 (Streamable HTTP) lands, forward http mcpServers to runtimes that declare the capability (buzz-agent would need to declare it; rmcp already supports streamable HTTP).
When a desktop agent runs through a tier-2 preset (omp, hermes) or a custom harness, the desktop app never passes an MCP server to the runtime:
BUZZ_ACP_MCP_COMMANDis derived only fromknown_acp_runtime(goose/claude/codex/buzz-agent), so it is always empty for omp/hermes/custom runtimes, and there is no other injection channel. The same MCP config works fine in omp/goose/codex/claude-code/opencode directly: ACP v1 natively defines stdio/http/sse MCP servers (agentclientprotocol/agent-client-protocol, schema/v1/schema.json), all accept client-injected mcpServers, and omp declares http+sse capability in initialize — so this is a Buzz-specific gap.Use case: A user runs open-connector (streamable HTTP MCP with Bearer auth) against Notion. It works in omp's interactive sessions, but cannot reach a Buzz agent running on omp — we had to bridge stdio→HTTP ourselves.
Evidence (HEAD 857e63c):
desktop/src-tauri/src/managed_agents/runtime.rs:527-529(+ 294-298, 466-469): MCP command derived only viaknown_acp_runtime(effective_command); comment: "pure derivations of the command… rather than the frozen record snapshot"desktop/src-tauri/src/commands/agent_models.rs:884-888: "the per-record field is never read by the runtime";types.rs:258-262"Never read at spawn";runtime_metadata.rs:9-10"Vestigial"desktop/src-tauri/src/managed_agents/custom_harnesses.rs:49-75:HarnessDefinitionhas nomcp_command; definition env filtered againstRESERVED_ENV_KEYS(env_vars.rs:73includesBUZZ_ACP_MCP_COMMAND), andvalidate_user_env_keysrejects on savediscovery/presets.rs:104-112: omp is a tier-2 preset, butKNOWN_ACP_RUNTIMES(discovery.rs:75-180) has only goose/claude/codex/buzz-agent →known_acp_runtime("omp")= Nonecrates/buzz-agent/src/lib.rs:302-310: initialize declaresmcpCapabilities {http:false, sse:false};mcp.rsonly rmcpTokioChildProcess(stdio)crates/buzz-acp/src/config.rs:261→lib.rs:4280: single stdio server fromBUZZ_ACP_MCP_COMMANDProposal:
BUZZ_ACP_MCP_CONFIG) into the desktop spawn path, for preset and custom runtimes alike. WhenBUZZ_ACP_MCP_CONFIGis absent, keep the existingknown_acp_runtime-derived command as the fallback so default behavior is unchanged. The managed-agents reconciler (migration.rs:975/1220) must recognize the new config source, or startup will rewritemanaged-agents.jsonfrom the directory table and clobber the new channel.httpmcpServers to runtimes that declare the capability (buzz-agent would need to declare it; rmcp already supports streamable HTTP).BUZZ_PRIVATE_KEY/BUZZ_AUTH_TAG.Related: #2899 #2900 #3115 #3399 #4154 #4164 #4271 #4301 #4480 #4515