Periodic MCP reconnect notifications flood conversation history, even while the session is idle

Start by inspecting the installed app.js behavior around handleStarting, handleConnected, and the timeline mapper, then review events.jsonl persistence and the repeated MCP reload evidence. Add a regression test for repeated background refreshes with slow-successful and failed servers; done means failures remain actionable while repeated lifecycle entries no longer flood conversation history and connection history remains accessible.

Describe the bug

A long-running Copilot CLI session repeatedly appends individual MCP lifecycle messages to the main conversation, including "is taking longer than expected to connect" followed by "connected." The same servers appear repeatedly. Returning after leaving the session idle requires scrolling past many screens of infrastructure messages to find the last useful response.

This is not just a redraw artifact. During the observed interval on September 18, 2026, the process logs recorded 29 forced MCP graph reloads and 29 full host replacements. The session journal persisted 261 slow-connection/recovery messages: 184 warnings and 77 connection confirmations. There were no user messages in this session between 07:00 UTC and the report at 19:33 UTC. These messages obscure both the conversation and genuinely actionable MCP failures.

The CLI owns the presentation of these lifecycle events. A slow server or legitimate background refresh should not cause unbounded, expanded notification history.

Affected version

GitHub Copilot CLI 1.0.84-9

Steps to reproduce the behavior

1. Start or resume an interactive copilot session with multiple configured or plugin-provided MCP servers. The affected environment uses enterprise managed settings.
2. Use the session normally, then leave it open without submitting more prompts for at least an hour.
3. Return and inspect the main conversation. Repeated groups of per-server slow-connection warnings and connection confirmations have been appended.
4. Leave the session open across further refresh cycles. More groups accumulate, requiring substantial scrolling to recover the previous conversation.

This is the observed long-running-session path, not a clean-profile reproduction. In the captured process, managed-settings self-fetches occurred approximately hourly and were followed by forced MCP reloads. Most cycles also had a second reload shortly afterward.

Expected behavior

Background MCP lifecycle updates must not overwhelm the conversation. Present them in one compact, collapsed-by-default, expandable MCP status section, updating each server's latest state instead of appending repeated warning/recovery pairs. Keep actual failures and authentication-required states visible and actionable. Retain detailed connection history inside the expandable section or diagnostic logs. Avoid unnecessary full host replacement when the effective MCP configuration has not changed.

Additional context

Additional context

• Logs: Existing DEBUG-level process logs and the session event journal were inspected. Attach the focused, sanitized copilot-mcp-startup-evidence-d704dc97-de78-4b46-8974-a9b94f206b5e.json and the screenshot of the message flood.
• OS: Windows 11 Enterprise, version 10.0.26200, build 26200.
• CPU architecture: x64.
• Terminal: Windows Terminal Preview, package 1.25.1912.0; executable product version 1.25.260710002-preview.
• Shell: PowerShell 7.6.6.
• Full debug-logs attachment: Not collected or uploaded. The local session contains unrelated private work. This CLI supports /collect-debug-logs file [path]; review any full bundle before sharing.

copilot-mcp-startup-evidence-d704dc97-de78-4b46-8974-a9b94f206b5e.json

Session ID: d704dc97-de78-4b46-8974-a9b94f206b5e.

Version caveat: The running process and its in-use package are 1.0.84-9, build commit 9e271da1. The affected-version output above was captured with copilot --prefer-version 1.0.84-9 --version. A fresh copilot --version now prints 1.0.86-2. This report does not claim reproduction on 1.0.86-2.

Confirmed implementation behavior

Inspection of the running build's installed app.js shows:

• handleStarting arms a per-server timer with a default threshold of 10,000 ms.
• When the timer expires, it emits a session.warning for that server.
• handleConnected emits a separate session.info if a slow-connection warning was emitted.
• These calls do not request ephemeral events. The events are persisted in events.jsonl, and the timeline mapper appends separate warning/info entries rather than updating a single server status.
• Starting another cycle can emit the pair again; the slow-warning state is not a session-wide deduplication mechanism.

Confirmed log correlation

The scoped interval is September 18, 2026, 07:00:00-19:33:12 UTC. All 261 counted notifications were emitted between 07:24:53 and 19:25:40 UTC, before the user reported the problem. Thirteen approximately hourly managed-settings self-fetches appear in the retained process logs.

The last observed cycle included:

19:24:42.257Z  managed-settings self-fetch begins
19:24:42.806Z  session.managed_settings_resolved is delivered
19:24:42.812Z  mcp graph load: reload {"force":true}
19:24:43.206Z  mcp discover_and_start_root: full replace_host path
19:24:54.020Z  slow-connection warnings begin
19:25:10.138Z  connection confirmations begin
19:25:21.573Z  Reloaded hooks after plugin change (4 total)
19:25:21.584Z  mcp graph load: reload {"force":true}
19:25:21.994Z  mcp discover_and_start_root: full replace_host path
19:25:32.050Z  another batch of slow-connection warnings begins

The same reloads report sandbox_changed:false and policy_already_applied:true. That does not prove that every effective configuration input was unchanged. The evidence establishes real repeated reloads and persistent notification spam, but the exact reason the refresh/reconciliation path requests each forced reload still needs maintainer investigation.

Suggested regression guard: Simulate repeated background refresh cycles with slow-but-successful and failed servers. Assert that conversation history does not gain repeated expanded entries, while failure details remain visible and connection history remains accessible.

copilot-mcp-startup-evidence-d704dc97-de78-4b46-8974-a9b94f206b5e.json