allowedMcpServers entries using serverName never match

[rpstester]

Describe the bug

allowedMcpServers entries using serverName never match — named servers are blocked as "not permitted by enterprise managed allow list"

serverName matchers in a server-managed allowedMcpServers policy don't match anything. A server whose label exactly matches a serverName entry is blocked the same way as a server that isn't on the list. In the same session, serverUrl and serverCommand entries in the same policy work as expected.

The docs say serverName "matches the user-assigned server label exactly" and applies to "any server":
https://docs.github.com/en/copilot/reference/enterprise-administrators/enterprise-managed-settings#allowedmcpservers

The docs don't describe any condition that disables serverName matching. For example, they don't say it applies only when the list has no serverUrl or serverCommand entries. If that is the intended behavior, it isn't documented.

This is Copilot CLI 1.0.89, GitHub Copilot app 1.1.23, Windows 11 (build 26200).

This is a server-managed team policy file (.github-private), applied through overridable at the enterprise level. Here is a shortened version. The client cache shows the full list was received (keys=[allowedMcpServers,...], all entries present):

{
  "allowedMcpServers": [
    {"serverUrl": "https://learn.microsoft.com/api/mcp"},
    {"serverName": "workiq"},
    {"serverName": "azure-devops"},
    {"serverName": "miro-mcp"},
    {"serverUrl": "https://mcp.miro.com"},
    {"serverCommand": ["npx", "-y", "next-devtools-mcp@latest"]}
  ]
}

Affected version

GitHub Copilot CLI 1.0.89.

Steps to reproduce the behavior

1. Apply a server-managed policy like the one above.
2. Add these servers with --additional-mcp-config. Use a minimal stdio MCP server for node mini.js.

   {"mcpServers":{
     "workiq":           {"type":"local","command":"node","args":["mini.js"]},
     "zz-not-listed":    {"type":"local","command":"node","args":["mini.js"]},
     "appian-dev-tools": {"type":"http","url":"https://mcp-probe.invalid/mcp"}
   }}

3. Run:
   copilot -p "Reply OK" --additional-mcp-config @extra.json --log-level all --log-dir ./logs

Expected behavior

workiq and appian-dev-tools should start, because they match serverName entries. zz-not-listed should be blocked.

Instead, all three are blocked with identical messages. The remote probe URL is never contacted.

[DEBUG] Skipping MCP server "zz-not-listed": not permitted by enterprise managed allow list
[DEBUG] Skipping MCP server "appian-dev-tools": not permitted by enterprise managed allow list
[DEBUG] Skipping MCP server "workiq": not permitted by enterprise managed allow list

In the same run, servers that match a serverUrl entry (for example Microsoft Learn and Miro) or a serverCommand entry (for example next-devtools-mcp) connect normally.

Before we added serverUrl/serverCommand entries, 8 of our 10 configured servers were blocked even though every one of them had an exact serverName entry. Only the 2 servers with serverUrl entries loaded. Adding serverUrl/serverCommand duplicates is our workaround.

Additional context

• The block isn't visible to users. The skip is logged only at DEBUG. In the Copilot app's MCP settings, the blocked servers show a spinner that stops after about 20 seconds with no status icon, error, or policy message. Users see a blank row. Other servers in the same list show a green check or an error badge, as expected.
• Related, but a different cause: Managed-settings interim fail-closed uses an empty allow list ([[]]) and permanently drops user MCP servers that register inside the window — reproduces via the desktop app, on an account with no managed policy #4419 and 1.0.88: workspace MCP servers blocked at startup because managed policy is resolved before GitHub auth #4957 cover servers dropped by an interim or early fail-closed policy. In our case the policy resolves normally (source=server, serverFetchFailed=false) and the named servers are still blocked on every run.
• I can share full DEBUG logs on request.