Local stdio MCP server silently dropped during session-ID swap on startup (resume and  /new )

Start with the session startup and foreground-session registration flow, using the ~/.copilot/logs/process-.log sequence as the reproduction trace. Compare the teardown and reconnect handling for github-mcp-server with the local stdio server during the session-ID swap. Reproduce with --resume or /new and verify that the local server is registered under the real session and its tools appear in tool_search_tool.

CLI version: 1.0.86 (also reproduced on 1.0.67 in a parallel session)

Summary:
On every session start — both  --resume  and a fresh  /new  session — the runtime briefly creates a placeholder/foreground session, connects all configured MCP servers to it, then swaps in the real session ID. During that swap,  github-mcp-server  (remote) is correctly torn down and reconnected to the new session. A local stdio server ( mas-devops , our custom MCP server) is not reconnected — it remains bound to the discarded placeholder session and never appears in the tool catalog for the real session, even though its process is alive and its one-and-only MCP handshake succeeded. Result: the CLI reports the server as connected in  mcp list , but  tool_search_tool  finds zero tools for it, and any call to it fails with  "MCP server is not connected" .

Reproduction (100% reproducible, 2 independent trials):

1. Configure a local stdio MCP server in  ~/.copilot/mcp-config.json  ( type: local ,  command ,  args ,  env ).
2. Start a session via  copilot --resume=  or  /new  from within an existing session.
3. Inspect  ~/.copilot/logs/process-.log :
   •  Registering foreground session:  
   •  mas-devops-mcp  →  Service initialized as client  (single occurrence, tied to   )
   •  Unregistering foreground session:  
   •  Registering foreground session:  
   •  github-mcp-server  →  task cancelled  /  serve finished {quit_reason: Cancelled}  → new  Service initialized as client  (reconnected under   )
   •  mas-devops-mcp  → no further log lines at all — never torn down, never reconnected.
4.  tool_search_tool  with pattern matching the local server's tool prefix → 0 results, even though  ps  shows its process alive and  copilot mcp get   shows  Status: Enabled .

Expected: Local stdio servers should be reconnected (or at minimum re-registered against the real session) using the same teardown+reconnect logic already applied to remote servers during the session-ID swap.

Actual: Only the remote server observed ( github-mcp-server ) gets that reconnect; the local stdio server is silently orphaned, with no error surfaced to the user except a delayed, easy-to-miss  PluginsScreenDetail listMcpTools() failed: Error: MCP server "" is not connected  line.

Workarounds attempted, none effective:

• Restarting the CLI ( /restart ) — same defect recurs.
• Starting a brand-new session ( /new ) instead of resuming — same defect recurs identically.
•  copilot mcp disable   +  copilot mcp enable   mid-session — no effect (config toggle doesn't force a live reconnect).
• Clearing  ~/Library/Caches/copilot/mcp-tools/*.json  (unrelated stale-cache warnings were also present) — no effect on this specific issue.
• Killing and letting the orphaned child process re-spawn — not possible; per documented behavior, local stdio MCP connections cannot be reconnected mid-session once dropped.

Impact: Any custom/local stdio MCP server becomes permanently unusable for the lifetime of a session, with no user-facing recovery path short of hoping a future session start doesn't hit the race. Remote MCP servers are unaffected.

mcp-bug-report.tgz