Extension hosts and all MCP servers are re-enumerated on an hourly in-session reload cycle

Reproduce a long-running session with CLI 1.0.85, six extensions, and five MCP servers, then inspect the extension launch logs and the %LOCALAPPDATA%\copilot\mcp-tools cache across reloads. Done means unchanged sessions keep their extension hosts and MCP connections without hourly teardown, re-enumeration, or unbounded cache and log growth.

Corrected 2026-09-17. The original version of this report claimed extension hosts are never reaped and cited 20 leaked processes / 4.3 GB. That was wrong and has been removed — see the correction comment below. The reload and MCP re-enumeration behaviour described here has been re-verified.

Summary

In a long-running interactive session, the CLI respawns its full set of extension-host processes on a recurring hourly cycle. Each reload tears down and re-enumerates every configured MCP server, which surfaces to the user as MCP servers repeatedly "connecting/disconnecting".

Process lifetime is handled correctly — the previous generation is reaped when the new one starts. The issue is the reload cadence itself and the MCP churn it causes.

Expected vs actual

• Expected: a stable session with unchanged configuration keeps its extension hosts and MCP connections up.
• Actual: hosts are torn down and respawned hourly, and every MCP server is re-enumerated from scratch each time.

No configuration or extension source file changed during the observation window — the newest extension .mjs mtime was over a day older than any reload.

Evidence

One session with 6 local extensions, reloading hourly without interruption (from extension launch logs):

00:05  01:05  02:05  03:05  04:05  05:05  06:05
07:05  08:05  09:05  10:05  11:05        (16 events in one day)

Three concurrent sessions each reload on their own start-anchored offset (:05, :52, :52), so a registry rebuild occurs every 20–30 minutes machine-wide.

Steady state is exactly 6 hosts per session, one generation each:

ca8e1e32 : 6 hosts, generation 11:06
ee4cd246 : 6 hosts, generation 11:52
efb20392 : 6 hosts, generation 11:52

Cache is re-written but never re-used

The MCP tool cache under %LOCALAPPDATA%\copilot\mcp-tools is rewritten at each reload under a new hash, so it never hits — the same servers are re-enumerated from scratch every cycle and the directory grows without bound. Currently 225 files / 12.2 MB, with identical payload sizes recurring across generations.

Log volume

Each reload writes a fresh log per extension: 558 files in one day, 1,242 total.

MCP side effect

3 OAuth-backed remote MCP servers dropped at a reload boundary and did not return for ~14 hours, while 2 non-OAuth servers rode through untouched. Possibly related to #4842, but without the self-heal described there.

Related

• #4842 — concurrent MCP OAuth refresh cancelling a reconnect.
• #4468 — extension-host leakage across sessions under --server --stdio. Referenced for contrast: that leak is not what is happening here.

Environment

• CLI 1.0.85, Windows 11
• 6 local extensions loaded from a repository's .github/extensions
• 5 MCP servers configured (2 local stdio, 3 remote OAuth-backed)
• 3 concurrent interactive sessions

Impact

Tool availability churns every 20–30 minutes on a machine running a few sessions, and in-flight MCP servers can fail to re-attach across the boundary. An hourly teardown of a healthy, unchanged configuration looks unnecessary.