MCP server 'blocked by policy'

[mydeveloperplanet]

Describe the bug

We have a custom MCP registry which is checked when local MCP servers are configured. Although the local MCP configuration is correct and works just fine within VSCode and IntelliJ plugin, an error message 'MCP server is blocked by policy' is shown.

It is unclear what causes this. The process log mentions the following:

2026-06-25T11:40:36.761Z [ERROR] MCP server "io.github.sooperset/mcp-atlassian" filtered: Server "io.github.sooperset/mcp-atlassian" found in registry <REDACTED> but local configuration does not match the registered server identity

Affected version

GitHub Copilot CLI 1.0.65

Steps to reproduce the behavior

1. Configure an MCP server in the mcp-config.json in the ~/.copilot directory or just install it from within the Copilot CLI with /mcp add
2. The MCP server is blocked

Expected behavior

No response

Additional context

No response

[wkimball]

We're ​hitting ​this same issue ​on GitHub ​Copilot ​CLI ​(currently 1.0.75) with an enterprise "Registry ​only" MCP ​policy ​and our own custom registry. A ​registry-listed server ​is rejected at ​startup with:
MCP server "" filtered: Server "" found ​in registry  ​but local ​configuration does not ​match ​the registered server ​identity
In ​our testing ​the pattern is consistent ​and runtime-specific:
All npx/npm-based registry ​servers we ​tried load ​fine ​with ​the ​registry config ​used verbatim (azure-devops, ​azure-cloud, apollo-graphql, db-toolbox).
All Docker/OCI-based registry ​servers ​are blocked (sonarqube, ​neo4j, figma-docker), even when the local config is ​copied ​exactly ​from the ​registry entry.
It does not ​appear to be ​a ​config-authoring problem on our side:
A completely ​different, ​non-Docker type: http config for the same ​registered server name is ​blocked with ​the identical ​"does ​not ​match ​the registered server ​identity" error ​-- so it isn't ​about docker ​run argument ​tokenization specifically.
The CLI's own experimental /mcp ​search -> install ​path (where the ​CLI builds ​the config ​directly from the ​registry) is also blocked: ​in experimental mode ​the ​server ​hangs ​on "connecting", and after ​restarting in normal ​mode ​it reports 1 MCP server was ​blocked by ​policy.
This looks like ​the same verifyServerIdentity fingerprint ​mismatch analyzed ​in #3162, ​where the fix ​special-cased ​npm ​flags but ​did not ​add equivalent normalization for Docker/OCI ​image references (or, per ​#4205, for ​HTTP headers). Our registry ​entry's package ​identifier is an OCI image ​reference ​(e.g. mcp/, runtimeHint: ​docker), ​and the local docker ​run ​... command adds ​standard flags ​(--init, --pull=always, -i, --rm, -e ​...) around that ​image -- ​which appears ​to be enough ​to fail the ​identity match.
Two questions ​for the maintainers:
What is the intended canonical identity computation for an oci/Docker ​manifest entry, ​and does ​the current implementation ​compute/compare it correctly?
Will the ​argument-normalization ​that was added for ​npm/npx flags be extended to Docker/OCI ​image references ​so registry-listed Docker ​servers ​can pass ​the ​identity ​check?
Happy to provide a full ​reproduction package ​(config, registry ​manifest excerpt, and CLI ​process ​logs) ​if ​that helps.

[sfraseraa]

Confirmed fixed in v1.0.78 — posting for anyone who lands here with the same Docker/OCI identity-mismatch block.

We hit this exact error ( local configuration does not match the registered server identity ) in an enterprise  registry_only  environment with a SonarQube Docker/stdio MCP server. GitHub support (Andy, 2026-08-04) confirmed v1.0.78 shipped a fix: the CLI no longer fingerprint-checks the local config against the registry's package metadata — it now only checks that the server name resolves in the configured registry.

Tested and confirmed working on v1.0.78 for two Docker/OCI servers:

•  sonarqube  (Docker stdio, env vars passed via  -e  flags in  args )
•  figma-docker  (Docker stdio,  docker.io/acuvity/mcp-server-figma )

Both had been blocked 100% of the time on earlier versions. Both connect cleanly on v1.0.78 with no config changes beyond upgrading.

Key config note: env vars must be passed into the container via  -e  flags inside  args , not via the top-level  env  block (which is not forwarded into Docker).

[copilot-cli-bot]

This appears to be resolved as of GitHub Copilot CLI v1.0.88. Please update to that release or a newer stable version. We're closing this as completed. If it still happens, please comment with your version and reproduction steps.