Remote/HTTP MCP servers (e.g. atlassian) are stranded 'failed' after every /clear or session relaunch

Summary

Remote (HTTP) MCP server connections are reliably stranded in a failed state whenever the CLI performs a foreground-session handoff — which happens on every /clear, and apparently on session resume/relaunch too. The MCP connection graph is torn down and rebuilt during the handoff, and slower remote/OAuth-backed servers lose the reconnect race and never recover automatically.

Environment

• CLI version: 1.0.83 (macOS, confirmed already latest via in-app update check)
• MCP server affected: atlassian (https://mcp.atlassian.com/v2/mcp, HTTP transport with Authorization header)
• Other MCP servers configured (github-mcp-server, codegraph, local-rag — local/stdio) are not visibly affected, likely because their reconnect is fast enough to win the race.

Steps to reproduce

1. Start a Copilot CLI session with the atlassian MCP server configured (~/.copilot/mcp-config.json, HTTP transport).
2. Confirm it connects fine (/mcp show atlassian → connected, tools listed).
3. Run /clear (or relaunch/resume a session).
4. Run /mcp show atlassian again.

Expected

atlassian reconnects cleanly like the other MCP servers.

Actual

atlassian is left in:

{
  "name": "atlassian",
  "status": "failed",
  "error": "MCP server \"atlassian\" connection was cancelled"
}

It does not self-heal — it requires a manual reconnect action or a full CLI restart, and even a full restart reproduces the same failure deterministically (confirmed across two separate relaunches, ~20 minutes apart).

Root cause (from ~/.copilot/logs/process-*.log)

Every /clear/relaunch briefly registers a throwaway foreground session, then immediately unregisters it in favor of the real one, within milliseconds:

17:27:22.425Z [INFO] Registering foreground session: 6266dbfb-39da-4797-9265-c37d9655a3fd
17:27:28.717Z [INFO] Unregistering foreground session: 6266dbfb-39da-4797-9265-c37d9655a3fd
17:27:28.720Z [INFO] Registering foreground session: d89d1d9a-99c4-4247-86fe-a75b4da5daad
17:27:28.783Z [INFO] Closing session 6266dbfb-39da-4797-9265-c37d9655a3fd

This handoff triggers a full MCP graph reload while a reload lock is still held from the previous teardown:

17:05:05.167Z [WARNING] [rust:copilot_runtime::session::mcp::session_host] MCP reload lock still held at disposal; draining the graph without it

Every MCP server — including atlassian — gets re-initialized and then almost immediately cancelled mid-handshake:

17:27:26.104Z [INFO] [rust:rmcp::service] Service initialized as client {... "name": "atlassian-mcp-server" ...}
17:27:28.809Z [INFO] [rust:rmcp::service] task cancelled
17:27:28.809Z [INFO] [rust:rmcp::service] serve finished {"quit_reason":"Cancelled"}

Local/stdio servers appear to reconnect fast enough afterward to recover; atlassian's remote HTTP+OAuth handshake is slower and consistently loses the race, leaving it permanently failed with no automatic retry.

Confirmed not a network/auth issue independently:

• DNS resolves fine for mcp.atlassian.com.
• curl https://mcp.atlassian.com/v2/mcp returns 401 (server reachable, no valid header supplied in the manual test — expected).
• ATLASSIAN_MCP_AUTH_HEADER env var is set.

Impact

Every /clear (a very common action) breaks the Atlassian MCP integration and requires a manual reconnect or CLI restart to restore it — significant daily friction for anyone using an HTTP-based MCP server.

Suggested fix

• Don't tear down/reinitialize already-connected MCP servers on a foreground-session handoff that isn't actually changing MCP config.
• If a reload is unavoidable, retry a server that was cancelled mid-handshake instead of leaving it permanently in failed state.
• Respect the "MCP reload lock still held at disposal" case by waiting for the lock instead of draining the graph without it.

Reproduisez l’échec avec un HTTP server configuré dans ~/.copilot/mcp-config.json, puis examinez les logs du transfert de la session au premier plan et de copilot_runtime::session::mcp::session_host autour du MCP reload lock. Comparez le comportement de /clear et du relancement avec la séquence d’annulation documentée. Le travail est terminé lorsque le serveur distant reste connecté ou récupère automatiquement après l’un ou l’autre transfert, sans nécessiter de reconnexion manuelle.