Repository navigation
All MCP servers blocked by policy when GHE returns 404 on /copilot/mcp_registry #2498
Description
Activity
Same here. On Enterprise Copilot, v1.0.19 and all the MCPs are disabled except the built-in one.
This is still an issue in GitHub Copilot CLI 1.0.20.
Reacted by KhizarHi @grantborthwick we are working on it, fix is incoming 🚀
Reacted by Grant Borthwick and KhizarFYI still getting this issue with GitHub Copilot CLI 1.0.21
Reacted by KhizarThe same, still getting similar issue with GitHub Copilot CLI 1.0.21 (on different GHE account, without no registry configured or registry policy configured to AllowAll)
Reacted by KhizarSame here . This is still an issue in GitHub Copilot CLI 1.0.21
Hi folks - please logout from your cli and login again. CLI will refetch the auth data including the mcp registry settings.
Reacted by EmprintYes this solved it!
Hi folks - please logout from your cli and login again. CLI will refetch the auth data including the mcp registry settings.
Already done previously, but tested again right now, with /logout, terminate CLI, open CLI and /login again.
Registry settings are not updated and the same issue is still present. It also seems that registry settings are not correcly retrieved:
in the logs I can see the CLI tries to fetch "https://burger-mcp-registry.com" and "https://copilot-mcp-registry.github.com", which the IT admin never configured.Update: I've also double-checked on a different machine, with a different user account, which never had Copilot CLI installed (used v1.0.21 on Windows, no WSL). Same issue, with the same registry URLs checked for the policy (and fail with 404, given that those endpoints do not exist).
Reacted by Christian Dancke Tuen and Vladimir SutskeverSolved it for me as well. Thanks!
Spoke to soon..
It is partially fixed (under WSL atleast). As soon as I restart the copilot cli the MCP:servers are disabled again due to the same policy restricitons. So the fix is to once again /logout & /login without restarting the cli. Also be fast accepting the local storage of the keys. Taking to long in this step will make the MCP be disabled again and you have to /logout & /login again for it to work.
This can only be regarded as a workaround, since loging out and logingn in each time you restart or start a new terminal is not the best experience.
It does seem like these "registry_only" entries should not have been pushed to production? (the same ones as @gianni-rg mentions above)
$ gh api /copilot/mcp_registry { "mcp_registries": [ { "url": "https://mcp.azure.com/", "registry_access": "allow_all", "owner": { "login": "github", "id": 1, "type": "Business", "parent_login": null, "parent_id": null, "priority": 1 } }, { "url": "https://burger-mcp-registry.com/", "registry_access": "registry_only", "owner": { "login": "bobs-burgers", "id": 3097, "type": "Organization", "parent_login": "github-inc", "parent_id": 2, "priority": 2 } }, { "url": "https://copilot-mcp-registry.github.com/", "registry_access": "registry_only", "owner": { "login": "standalone-org", "id": 507, "type": "Organization", "parent_login": null, "parent_id": null, "priority": 3 } } ] }Per GitHub's MCP Allowlist Enforcement documentation:
"When 'Registry only' is configured, the system restricts MCP servers to those registered in your organization's registry."
"Stricter policies ('Registry only') take precedence over permissive ones ('Allow all')"
Even though the first entry has
allow_allat priority 1, theregistry_onlyentries override it because stricter policies always win. Since the fake registries don't contain any real servers, all user MCP servers are blocked.I'm still seeing this after /logout and /login on 1.0.21 and then starting a new session:
Hi again, please relogin one more time, the issue should be fixed now. Thank you for your patience!
Reacted by Grant Borthwick and Christian Dancke TuenHi again, please relogin one more time, the issue should be fixed now. Thank you for your patience!
Just tested. It seems working now. Thank you for the support!
Reacted by JoannaaKLWorking on my side as well so far, thank you!
Reacted by JoannaaKL@JoannaaKL - it started working for me now without re-login again - thanks!
Reacted by JoannaaKL@JoannaaKL While this issue is fixed when running directly from the terminal (thank you very much for this!), the issue remains when running Copilot CLI from VS Code Insiders in both
github.copilot.cli.newSessionandworkbench.action.chat.openNewSessionEditor.copilotcli, any idea what could cause this?
I suppose I need to forward the issue to the VS Code team.
Reacted by JoannaaKL
Describe the bug
On GitHub Enterprise (microsoft.ghe.com) with an Enterprise Copilot plan, all non-default MCP servers are blocked at startup with "19 MCP serverswere blocked by policy". The GHE instance returns HTTP 404 for GET /copilot/mcp_registry because it doesn't support the MCP registry API yet. The CLI treats this 404 as a policy fetch error and blocks all servers, rather than treating it as "no registries configured" (which should allow all).
The pLn() function in app.js throws on 404, and the NEe() catch block returns yEe([]) (empty registry = block all). A 404 should instead return { mcp_registries: [] } so it flows into the o.length === 0 path which uses the Wgn allow-all filter.
Log evidence:
[ERROR] Request to MCP registry policy at https://api.microsoft.ghe.com/copilot/mcp_registry failed with status 404 (request ID:
E1B4:18EBE6:19AB3B:B4DE37:69CEDD72)
Affected version
GitHub Copilot CLI 1.0.17
Steps to reproduce the behavior
Expected behavior
When /copilot/mcp_registry returns 404, the CLI should treat it as "no registries configured" and allow all MCP servers (same as the no_registries outcome path). The 404 means the feature isn't available on this GHE version, not that servers should be blocked
Additional context