Startup reports disabled MCP servers as “blocked by policy” and repeats the warnings #5222

Description

Copilot CLI displays organization-policy warnings at startup even though every configured third-party MCP server is explicitly disabled through disabledMcpServers in the user settings. The same pair of warnings appears twice during startup.

Environment

• Copilot CLI: 1.0.101
• OS: Windows
• Shell: PowerShell
• MCP configuration includes user-configured and plugin-provided servers.

Steps to reproduce

1. Have third-party MCP servers configured.
2. Disable all of them through the CLI, persisting their names in disabledMcpServers.
3. Start a new interactive CLI session with an account for which the CLI reports that third-party MCP servers are disallowed by organization policy.
4. Observe the startup warnings.

Actual behavior

Startup displays:

Third-party MCP servers are disabled by your organization's Copilot policy. Only built-in servers are available.

9 MCP servers were blocked by policy: ...

Both messages appear twice in the observed startup. Every server named in the warning is already explicitly disabled in the user settings.

Expected behavior

• Already-disabled servers should not be counted as servers blocked by policy at startup.
• An unchanged policy notice should not be repeated during startup refreshes.
• If a general policy notice is intentional, it should be clearly informational and distinguish organization restrictions from user-disabled servers.

Investigation notes

Read-only inspection of the locally installed 1.0.101 bundle found:

• In cli-main.js, reloadMcpServersExclusive() passes the configured server map to the policy filter without disabled-server settings. Disable settings are handed to the native lifecycle afterward.
• The interactive initialization path emits the general policy warning based on policy allowance, without checking whether any third-party servers are enabled.
• The general and filtered-server warnings have no deduplication at these emission points, allowing repeated initialization/reload calls to emit them again.

These observations explain the reporting behavior; they do not establish that disabled servers are launched. The exact trigger for the second initialization/reload has not been identified.

Related issues

• MCP servers reported as "blocked by policy" on first launch when using a custom config directory #2567 - incorrect startup "blocked by policy" reporting in a different configuration scenario.
• Periodic MCP reconnect notifications flood conversation history, even while the session is idle #4907 - repeated MCP lifecycle notifications.