1.0.42 falsely reports registry-listed custom MCP servers as blocked by policy

[goldsziggy]

Describe the bug

Describe the bug

In Copilot CLI 1.0.42, a custom MCP server is being labeled as blocked by policy even though that
same server is already present in the MCP registry and should be allowed.

This looks like a false-negative in the CLI's registry validation / matching logic. The problem is not
that the server is unregistered; it is registered, but copilot still reports it as blocked.

This appears related to, but distinct from, earlier registry-policy issues such as #2604. In this case,
the server exists in the registry and is still rejected.

This happened immediately after updating.

Affected version

1.0.42

Steps to reproduce the behavior

1. Configure MCP policy so custom servers must be allowed from the registry.
2. Add a custom MCP server to the MCP registry.
3. Configure the same server locally for Copilot CLI.
4. Start copilot.
5. Observe that the CLI reports the server as blocked by policy instead of allowing it.

Expected behavior

If a custom MCP server is present in the MCP registry and matches the configured server, Copilot CLI
should allow it to load.

Additional context

Actual behavior

Copilot CLI 1.0.42 reports the custom MCP server as blocked by policy even though it is present in the
registry.

Additional context

• Previous version was 1.0.39
• This seems to be a registry matching / allowlist evaluation bug, not a registry fetch failure.
• Similar symptom: MCP Server Blocked by policy despite being allowed by MCP registry #2604, but this report is specifically about 1.0.42 incorrectly rejecting a server
  that is already in the registry.

[goldsziggy]

Burned some quick tokens confirming behavior:

• 1.0.39: if GET /v0.1/servers/{name}/versions/latest returned 200, the server was treated as
  found/allowed.
• 1.0.42: after lookup succeeds, the CLI now runs verifyServerIdentity(...), computes a local fingerprint,
  computes registry fingerprints from packages/remotes, and blocks the server if they don’t match.

What likely changed semantically in 1.0.42-era behavior

• Before: name exists in registry was enough.
• Now: name exists + local config fingerprint must match registry identity.

Likely mismatch sources

1. Local command/package vs registry remote/package shape don’t fingerprint the same way.
2. URL normalization differences: trailing slash, path differences, localhost vs 127.0.0.1, transport
   type.
3. Package identity differences: local install source/version/command wrapper differs from what the
   registry declares.
4. Command-based local MCP may now be considered unverifiable or differently fingerprinted than a registry
   package/remote.

Best issue framing

1.0.42 introduced strict local-vs-registry identity verification for MCP servers, causing previously
working registry-listed local MCP servers to be blocked after upgrade with no config changes.

And the key evidence to include is:

• 1.0.39 behavior: registry lookup 200 was enough to allow
• 1.0.42 behavior: verifyServerIdentity + fingerprint comparison now required
• Observed log: found in registry ... but local configuration does not match the registered server
  identity

That makes this much stronger than “blocked by policy” alone: it identifies the regression as new
fingerprint-based identity validation.

[goldsziggy]

After more investigation it is specifically due to entries like:

"custom-enterprse/sdlc-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "--registry",
        "https://artifactory.private-registry.com/artifactory/api/npm/npm",
        "@custom-enterprise/sdlc-mcp@1.0.0"
      ],
      "gallery": "https://developer.private-registry.com/mcp-registry",
      "version": "1.0.0"
    }

In this scenario; the --registry specification is causing the fingerprinting logic to error out. The server in this case is specifically is looking for the command to be @custom-enterprise/sdlc-mcp@1.0.0

While in theory the --registry is not needed with properly scoped global .npmrc, our workflow typically recommeds setting it regardless (just-in-case). In an ideal world; the mcp registry should allow specifying internal registries for npm/npx like commands.