ACP agents receive an empty mcpServers list at session/new, so agent-side MCP servers never load under bb

[ramaaudra]

Summary

I run omp (oh-my-pi) as an ACP provider in bb. In native omp CLI sessions, my MCP servers load from omp's own config and their tools work. In a bb thread on the acp-omp provider, the same agent loads zero MCP servers, so every MCP tool is gone. The ACP bridge sends a hardcoded empty mcpServers array at session/new, and there is no setting to declare the servers the client should pass.

Versions and environment

• bb 0.40.0 (desktop app), macOS 26.6.2
• provider-acp builtin plugin, agent acp-omp
• omp 18.0.5 (~/.bun/bin/omp)
• MCP server in question: codebase-memory-mcp v0.10.8, registered for omp as a local stdio server in ~/.config/opencode/opencode.json
• Local machine, no Connect, no custom data dir

Steps to reproduce

1. Configure an MCP server for omp CLI use, e.g. register codebase-memory-mcp (stdio) in ~/.config/opencode/opencode.json.
2. Confirm it works natively: run omp in a terminal and use one of that server's tools. omp's session log shows MCP prompt commands refreshed: <server>.
3. Start a thread in bb against the acp-omp provider.
4. Ask the agent to call any tool from that server.
5. The call fails with "No such tool".

Did not involve: other providers were not tested for this report, but the cause is in the shared ACP kit, so any ACP agent should be affected.

Expected vs actual

Expected: the agent gets the same MCP tools it has in native CLI sessions, because the client passes the server configuration at session/new per the ACP contract ("the client owns MCP server configuration"; see https://omp.sh/docs/acp).

Actual:

$ grep -c "MCP" ~/.omp/logs/omp.2026-08-26.10668.log   # ACP session log
0

$ grep "MCP prompt commands refreshed" ~/.omp/logs/omp.2026-08-25.*.log | head -1
"message":"MCP prompt commands refreshed: mcp:codebase-memory-mcp"   # native CLI session

The tools mounted in the ACP thread include only the internal proxy: ast_edit, debug, lsp, browser, mcp__bb_bridge_*. Probing one of my MCP tools returns "No such tool". omp's ACP mode intentionally does not read its own on-disk MCP config, so the missing layer is entirely on the client side.

Evidence

Root cause in packages/provider-bridge-acp/src/bridge/bridge.ts at 7dc6756e20ba749ad9d4d6d939b1dd7de363250b:

• buildSessionMcpServers() returns only the internal bb-bridge dynamic-tool proxy config, or an empty array when the thread has no dynamic tools:

  bb/packages/provider-bridge-acp/src/bridge/bridge.ts

  Lines 500 to 522 in 7dc6756

  	async function buildSessionMcpServers(
  	params: AcpSessionParams,
  	): Promise<AcpMcpServerConfig[]> {
  	const dynamicTools = params.dynamicTools ?? [];
  	if (dynamicTools.length === 0) {
  	return [];
  	}
  	const bridge = await ensureDynamicToolBridge();
  	const config = buildAcpMcpServerConfig({
  	bridgeArgs: resolveBridgeProcessArgsForMcpServer(),
  	command: process.execPath,
  	dynamicTools,
  	host: bridge.host,
  	port: bridge.port,
  	runtimeEnv: resolveBridgeProcessEnvForMcpServer(),
  	threadId: params.threadId,
  	token: bridge.token,
  	});
  	process.stderr.write(
  	`acp bridge: built "${config.name}" session MCP config for thread "${params.threadId}" (${dynamicTools.length} tools)\n`,
  	);
  	return [config];
  	}

• The model-discovery probe hardcodes the empty array outright:

  bb/packages/provider-bridge-acp/src/bridge/bridge.ts

  Line 940 in 7dc6756

  params: { cwd: agent.cwd ?? process.cwd(), mcpServers: [] },

• session/new and session/fork both consume that result; nothing merges in user-declared servers.

Proposed fix: add an optional mcpServers field ({ name, command, args, env }, the shape already exists in the kit as AcpMcpServerConfig) to acpLaunchSpecSchema in launch-spec.ts, append it in buildSessionMcpServers(). Because the provider-acp plugin builds its customAgents setting schema out of acpLaunchSpecSchema, the new field would flow through with no plugin changes, and users could declare per-agent servers in the existing Custom agents JSON. Additive change, no protocol bump; I estimate roughly 100 lines including tests. Happy to send the PR.

What you ruled out

• Not an omp misconfiguration: the same registration loads and answers in native CLI sessions, and omp logs confirm it.
• Not a stale or broken binary: codebase-memory-mcp v0.10.8 answers CLI queries fine from inside the same machine.
• Not the PATH problem: omp resolves on PATH for the daemon (that was a separate issue on my machine, fixed before this repro).
• Not acp-cursor sessions have no bb dynamic tools: bb-bridge MCP server not reachable despite unconditional attachment #2018: that issue is about the bb-bridge dynamic-tool proxy being unreachable for Cursor. My dynamic tools do arrive (mcp__bb_bridge_*); what never arrives is the user-declared MCP server list.
• Not first class oh my pi integration #1342: that asks for a first-class omp integration over RPC mode instead of ACP. I am reporting a gap inside the existing ACP path.

Suggested priority and effort

Affects every ACP agent user who configured MCP servers on the agent side (omp, opencode, Cursor all behave this way under ACP). Workaround exists today by calling the MCP binary over its own CLI from bash, which reaches the same state but loses the integrated tool UX. No data loss.