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):
- Configure a local stdio MCP server in ~/.copilot/mcp-config.json ( type: local , command , args , env ).
- Start a session via copilot --resume= or /new from within an existing session.
- 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.
- 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
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):
• 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.
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