v1.0.83: session resume cancels in-flight stdio MCP server connections (~1s timeout, was ~16s in v1.0.82)

[indeherb]

Describe the bug

Resuming an existing session cancels MCP server connections that are still initializing, causing
those servers to be silently unavailable for the entire session.

When a session is resumed, the CLI performs a foreground-session handover. Any MCP server whose
connection is still in flight at that moment is cancelled roughly one second after the handover
begins, and the CLI logs Failed to connect to MCP server "<name>": connection was cancelled.

This disproportionately affects stdio servers launched via npx -y, which need 15-20 seconds to
resolve and start. Fast-starting servers (local executables, HTTP servers) reconnect within that
one-second window and survive, so the same session ends up with a partial, inconsistent set of MCP
servers rather than an outright failure.

The affected servers are demonstrably healthy: they complete initialization and deliver their full
tool lists moments before being cancelled, and fresh tool-snapshot caches are written for them.
They are then discarded anyway, and the tools never become available to the model. There is also no
surfaced error in the interactive UI - the servers simply appear absent, which makes this look like
a configuration or authentication problem rather than a cancelled connection.

The cancellation is deterministic rather than intermittent: every resume of the same session
reproduces it. Because restarting the CLI typically resumes the previous session, the natural
recovery action does not resolve it, and the servers stay unavailable until a genuinely new session
is started.

Affected version

1.0.83

Steps to reproduce the behavior

Prerequisite: a stdio MCP server that takes >2s to start. An npx -y launcher guarantees this
(re-resolves the package on each spawn, 15-20s cold).

1. Configure a slow-starting stdio server alongside a fast one in ~/.copilot/mcp-config.json:

   {
   "mcpServers": {
   "chrome": {
   "type": "local",
   "command": "npx",
   "args": ["-y", "@playwright/mcp", "--user-data-dir", "C:\Users\\.mcp\chrome-profile"],
   "tools": [""]
   },
   "fast-server-1": { "type": "http", "url": "", "tools": [""] }
   }
   }

2. Start a NEW session: copilot
   All servers connect. Log shows Service initialized -> Playwright (17s after spawn); tools are
   available, cache written under %LOCALAPPDATA%\copilot\mcp-tools, no warnings.
   A fresh session tolerates arbitrarily slow starts (38s observed, still fine). Does NOT reproduce here.

3. Exit the session.

4. RESUME that same session (the trigger - not a fresh start): copilot --resume

5. Servers connect, then the handover cancels them ~1s later.
   ~/.copilot/logs/process-.log:

   08:37:37.342Z Service initialized -> Playwright
   08:37:40.148Z Service initialized -> slow-server-a
   08:37:40.691Z Service initialized -> local-exe-server
   08:37:41.370Z Service initialized -> fast-server-1
   08:37:41.634Z Service initialized -> fast-server-2
   08:37:41.863Z Unregistering foreground session:
   08:37:41.870Z Registering foreground session:
   08:37:42.442Z task cancelled (x2)
   08:37:42.442Z serve finished {"quit_reason":"Cancelled"} (x2)
   08:37:42.459Z Service initialized -> fast-server-1 <- fast servers reconnect in <1s
   08:37:42.595Z Service initialized -> local-exe-server
   08:37:42.691Z Service initialized -> fast-server-2
   08:37:42.911Z [WARNING] Error sending response {"id":"1"} <- server answered initialize after cancel

   ~/.copilot/session-state//events.jsonl:

   08:37:42.862Z Failed to connect to MCP server "slow-server-a": ... connection was cancelled
   08:37:42.893Z Failed to connect to MCP server "chrome": ... connection was cancelled

   Only fast servers reappear; slow ones are gone for the rest of the session.

6. Confirm unavailability - tools from the cancelled servers return nothing and the servers are
   absent from the tool manifest. No error surfaces in the interactive UI.

7. Restart the CLI. If it resumes the same session, step 5 repeats identically.
   Reproduced 3/3 resumes (05:04:07Z, 08:30:06Z, 08:37:42Z); 4/4 fresh sessions connected fine.

Contrast with 1.0.82 - same machine, same config, log from 2026-09-04: four handovers
(07:28:37Z, 19:35:59Z, 19:44:20Z, 20:37:51Z) each waited 13-16s for the same npx servers to
reconnect after "Registering foreground session", all succeeded. Zero warnings before the upgrade.

Note: the race is about timing, not specific servers. A normally-fast local .exe server was also
cancelled once, at 06:31:48.232Z, when it happened to start slowly.

Expected behavior

Resuming a session should preserve all configured MCP servers, regardless of how long they take to
start. The session-resume handover should either wait for in-flight MCP connections to complete, or
allow them to finish and register afterwards - as 1.0.82 did, waiting 13-16 seconds without issue.

Specifically:

• A resumed session should end up with the same set of available MCP servers as a fresh session
  using the same configuration. Startup latency should not silently determine which servers survive.

• Connections that have already completed initialization and returned their tool list should not be
  discarded. In the observed logs the servers deliver their tools and a tool cache is written, and
  the result is thrown away regardless.

• If a server genuinely cannot be connected, that should be surfaced in the interactive UI, not only
  buried in the process log and events.jsonl. As it stands the servers just appear absent, which
  points users toward debugging their configuration, credentials, or the servers themselves - none
  of which are at fault.

• Restarting the CLI after such a failure should recover. Because a restart normally resumes the
  previous session, the obvious remedy reproduces the same failure instead of resolving it.

If a timeout on MCP connection setup is intentional, it should be configurable, and its value should
be generous enough to accommodate npx-launched servers, which routinely need 15-20 seconds on a
cold start.

Additional context

Environment: Windows, Node v25.9.0, npm 11.9.0. Five MCP servers configured - two npx-launched
stdio, plus faster local and HTTP ones for contrast.

Ruled out - config is not the variable:

• mcp-config.json parses cleanly and was unchanged across both the working (1.0.82) and broken
  (1.0.83) periods.
• No enabled/disabled/trust/timeout fields. The affected servers use the same "tools": ["*"] as a
  server that connects fine.
• Credentials valid - the affected servers complete initialize and return their full tool lists
  on every launch, so auth demonstrably succeeds.
• No enterprise MCP policy in force (log: effective policy resolved: source=none).
• Both npx packages resolve and run fine when invoked manually.

Strongest evidence the servers are healthy: on the failing run, fresh tool-snapshot caches were
written for all five servers moments before two were cancelled. The tool lists were retrieved, then
discarded.

The [WARNING] Error sending response {"id":"1"} immediately after cancellation looks like a server
responding to an initialize whose transport was already torn down - may help locate the trigger.

Possibly related in the same release: 1.0.83 rejects the old cache format with
Unsupported MCP tool cache schema version: 1, suggesting the MCP subsystem was reworked.

Workarounds:

• Start a genuinely new session instead of resuming - fresh sessions connect reliably.
• Pre-installing the npx packages globally cuts ~15s of resolution, but isn't a guaranteed fix
  against a ~1s window.

Impact: the failure is silent and misleading - servers just appear absent with no UI error, and
since restarting resumes the same session, it persists across restarts. Significant time was lost
investigating config and credentials before the logs revealed the cancellation.

[Svudec]

Environment

• Copilot CLI version: 1.0.83 (upgraded from 1.0.81 immediately before this started)
• OS: macOS 15 (Darwin 25.6.0, arm64)
• Node.js: v22.22.2 (also reproduced under v24.20.0)
• MCP server: ado -> stdio, npx -y @azure-devops/mcp <org> --authentication azcli

Additional repro: also happens on genuinely new sessions, not only resume

In addition to /restart (session resume), this also reproduces when starting a brand-new
session with /new. Not just a resume-specific handover issue.

Log excerpt (redacted), showing ado's MCP handshake completing successfully,

then being cancelled ~10s later, before its tools are ever listed:

2026-09-07T09:16:19.588Z [INFO] Starting Copilot CLI: 1.0.83
2026-09-07T09:16:20.915Z [INFO] [rust:rmcp::service] Service initialized as client
  {"peer_info": ... "server_info": {"name": "Azure DevOps MCP Server", "version": "2.9.0", ...}}
2026-09-07T09:16:31.174Z [INFO] [rust:rmcp::service] task cancelled
2026-09-07T09:16:31.174Z [INFO] [rust:rmcp::service] serve finished {"quit_reason":"Cancelled"}
...
2026-09-07T09:16:52.737Z [WARNING] PluginsScreenDetail listMcpTools(ado) failed:
  Error: MCP server "ado" is not connected

Note: in this case the cancellation happened ~10s after the handshake completed, not ~1s
as described in the issue title, so the window may vary depending on server/timing.

Workaround that reliably fixes it every time: /mcp reload ado after the session is fully up.

[veriton-dev]

Host-ops notes: treat resume handover as a second MCP lifecycle, not a restart

The regression shape here is familiar from other agent hosts that tightened cancel budgets around session handoff: the old session's MCP graph is torn down with a short cancel window, and the new session only re-attaches whoever wins that race. Fast HTTP/local exe survive; cold npx -y stdio lose. Fresh sessions work because they never enter that dual-lifetime path.

Three clocks that should not share one budget

1. Handover / foreground-session swap — unregister A, register B. This is a host control-plane event, not an MCP error.
2. Transport reconnect / initialize — stdio spawn + initialize + tools/list. Cold npx routinely needs 10–20s; HTTP can be <1s.
3. Tool-ready registration — only after (2) settles should the model-visible tool manifest change.

If (1) cancels (2) with a ~1s budget, you get exactly the partial set described: healthy servers complete initialize, write a tool cache, then get quit_reason: Cancelled and never reappear. That is not a server fault.

Failure matrix worth separating in logs + UI

Mode	What happened	User-visible	Correct recovery
cancel-during-init	handshake in flight when handover fires	server absent	wait/rebind, do not mark permanently failed
cancel-after-init	tools/list already succeeded, cache written, then cancel	silent missing tools	re-register from cache or retry once without new spawn storm
hard connect fail	spawn/auth/protocol error	explicit error	surface name + reason in UI
slow-but-alive	initialize > budget but still progressing	looks like fail	progress heartbeat / configurable budget

Today cancel-after-init and hard fail both present as "server not connected," which burns time on config/credentials.

Concrete host policy (what 1.0.82 effectively did)

• Do not cancel in-flight MCP connects on resume unless the operator is quitting the process. Handover should re-parent or wait, not abort.
• If a timeout is required, make it per-server connect budget (default ≥15–20s for stdio, lower for HTTP), not a global ~1s handover timer.
• Preserve completed init: if tools/list already returned, keep the registration (or the cache snapshot) across the session id swap; only drop on hard error.
• Surface cancel distinctly: UI should say MCP "chrome" cancelled during session resume (connect budget exceeded) rather than vanishing the server.
• Restart must not re-enter the same trap: if default restart = resume, and resume always cancels slow servers, the obvious recovery is broken. Either force a true cold session after N cancel failures, or auto /mcp reload for cancelled names.

Acceptance checks that would have caught 1.0.83

1. Config: one HTTP MCP + one npx -y stdio that sleeps ~10s before ready.
2. Fresh session: both in tool manifest.
3. Exit → --resume (and /restart if that path differs): both still in manifest within connect budget; zero connection was cancelled for servers that completed initialize.
4. Intentionally kill only the slow server mid-init: UI shows named failure; fast server remains.
5. After a cancel-during-resume, /mcp reload <name> restores without full process restart (workaround already reported — good candidate for automatic recovery).

Why the tool-cache detail matters

Writing a fresh tool snapshot and then discarding the live connection is the worst of both worlds: disk says the server is healthy, runtime says it is gone, model sees neither tools nor error. Prefer: cache is advisory; live registration is authoritative; cancel after successful tools/list is a host bug, not a cache miss.

No product pitch — just the lifecycle split that keeps slow stdio MCP servers alive across resume the way 1.0.82 did.