SDK/server mode: session.create drops mcpServers — programmatically-provided MCP servers never start

[edwardsp]

Summary

When driving the Copilot CLI in server / SDK (programmatic) mode (copilot --server --stdio, via github-copilot-sdk), MCP servers provided on the session config (SessionConfig.with_mcp_servers(...) → the mcpServers field of the session.create request) are never started. The CLI's session.create handler does not forward mcpServers into the internal session it constructs, so initializeMcpHost() has nothing to start, no MCP tools are registered, and the model never sees them. The same MCP server works fine in interactive mode and standalone.

Environment

• Copilot CLI: reproduced on 1.0.51-2 and 1.0.64-0 (linux-x64)
• SDK: github-copilot-sdk (Rust) 1.0.1
• OS: Linux
• MCP server under test: official Azure MCP — npx -y @azure/mcp@latest server start --namespace kusto (stdio). Verified working standalone (responds to initialize + tools/list, exposes the kusto tool).

Steps to reproduce

1. Start a client via the SDK and create a session with an explicit stdio MCP server:

   let cfg = SessionConfig::default()
       .with_model("claude-...")
       .with_enable_config_discovery(false)
       .with_mcp_servers(HashMap::from([(
           "azure".to_string(),
           McpServerConfig::Stdio(McpStdioServerConfig {
               command: "npx".into(),
               args: vec!["-y","@azure/mcp@latest","server","start","--namespace","kusto"]
                   .into_iter().map(Into::into).collect(),
               ..Default::default()
           }),
       )]));
   let session = client.create_session(cfg).await?;
   session.send(/* a prompt that needs the MCP tool */).await?;

2. Send a prompt that requires the MCP tool.

Expected

The azure MCP server is started and its tools (e.g. azure-kusto) are registered and offered to the model.

Actual

• The server is never spawned (no @azure/mcp / npx child process), no MCP tools are registered, and the model reports the tool is not available — e.g. its own reasoning log: "I'm looking for the kusto tool in my available functions, but I don't see it listed directly … it's not showing up in my tools." The model falls back to other tools.

Evidence / root cause

1. The SDK does send the server. The session.create request received by the CLI contains it:

   {"enableConfigDiscovery":false,"enableSkills":true,
    "mcpServers":{"azure":{"command":"npx","args":["-y","@azure/mcp@latest","server","start","--namespace","kusto"],"type":"stdio","timeout":120000,...}},
    "model":"...","sessionId":"...","streaming":true,"tools":[]}

2. The CLI's session.create handler constructs the internal session by forwarding model, sessionId, systemMessage, largeOutput, availableTools, excludedTools, provider, enableStreaming — but not mcpServers (observed in the bundled app.js, both 1.0.51-2 and 1.0.64-0).
3. As a result initializeMcpHost() (which only acts when this.mcpServers / selectedCustomAgent.mcpServers is non-empty) never runs for these servers.

Workarounds tried (all fail in server mode)

• Upgrading the CLI 1.0.51-2 → 1.0.64-0: no change.
• GITHUB_COPILOT_MCP_JSON + GITHUB_COPILOT_3P_MCP_ENABLED=true: not read in server mode (readMcpConfigFromEnv() is not invoked; no "User-provided MCPs" log line appears).
• Config/plugin discovery (enable_config_discovery=true): does load plugin MCPs in server mode, but it pulls in all ambient servers — there is no supported way to inject a single explicit server in server mode.

The only thing that works is patching the bundled app.js to add mcpServers to the object passed to createSession(...), after which the server starts and azure-kusto is registered as expected — confirming the dropped field is the cause.

Related

• Title: ACP agent ignores custom JSON‑RPC methods and only exposes internal tool list #1574 (ACP/programmatic agent only exposes internal tool list)
• MCP servers configured but tools not exposed to AI assistant in Copilot CLI #191 (MCP servers configured but tools not exposed)

These touch the programmatic surface but don't call out the specific session.create → mcpServers drop.

[examon]

In the current CLI, the mcpServers provided to session.create in server/SDK mode are forwarded to the created session and started, subject to the normal MCP policy checks, so the field isn't dropped at session creation. I wasn't able to reproduce programmatic MCP servers failing to start on that path. If you're still hitting this, the cause is likely elsewhere (for example MCP policy or the server config shape) rather than session.create itself - please comment with the SDK config you're using and we'll take another look.