Describe the bug
/mcp search (interactive MCP registry browser) consistently fails with:
Failed to load registry: Error: Failed to fetch MCP registry policy: 400 Bad Request
whenever Copilot CLI is started inside a trusted folder whose git remote points to Azure DevOps (dev.azure.com) instead of a GitHub-hosted remote. This affects our entire engineering org, since 100% of our repositories are hosted on Azure DevOps.
Environment
- Enterprise: GitHub Enterprise Cloud with data residency / EMU tenant
- OS: Windows
- Enterprise MCP Registry: configured and verified working (Azure API Center-backed registry, "Registry only" policy) — confirmed via direct
curl calls that the registry itself returns HTTP 200 with the expected servers.
Workaround: Run /mcp search from a non-git folder to add servers once; they then work from any repo afterward via the persisted ~/.copilot/mcp-config.json.
Affected version
GitHub Copilot CLI 1.0.78
Steps to reproduce the behavior
- Configure an enterprise MCP Registry URL + "Registry only" policy (per GitHub docs).
cd into any local git repository whose origin remote is an Azure DevOps URL (e.g. https://org@dev.azure.com/org/project/_git/repo).- Start
copilot.
- Run
/mcp search.
- Observe:
Failed to load registry: Error: Failed to fetch MCP registry policy: 400 Bad Request.
cd outside any git repository (e.g. home directory) and start a fresh copilot process.- Run
/mcp search again → succeeds, returns all registry servers.
Expected behavior
/mcp search should successfully fetch the registry policy regardless of the git remote host of the current working directory, or at minimum should not derive repo/org context from non-GitHub git remotes in a way that breaks the request.
Additional context
- The failure is tied to process startup cwd/git-remote context, not conversation state:
/new inside the same running process does not recover it — only a full process relaunch outside a git-remote folder works.
- Once servers are added via the workaround below (outside a repo), they persist in
~/.copilot/mcp-config.json and connect fine from inside our Azure DevOps repos afterward — so the registry policy fetch specifically is what's broken, not general MCP connectivity.
- Reproduces consistently; not a timing/cache issue; not related to our enterprise's registry configuration (independently verified correct).
Describe the bug
/mcp search(interactive MCP registry browser) consistently fails with:Failed to load registry: Error: Failed to fetch MCP registry policy: 400 Bad Request
whenever Copilot CLI is started inside a trusted folder whose git remote points to Azure DevOps (
dev.azure.com) instead of a GitHub-hosted remote. This affects our entire engineering org, since 100% of our repositories are hosted on Azure DevOps.Environment
curlcalls that the registry itself returns HTTP 200 with the expected servers.Workaround: Run
/mcp searchfrom a non-git folder to add servers once; they then work from any repo afterward via the persisted~/.copilot/mcp-config.json.Affected version
GitHub Copilot CLI 1.0.78
Steps to reproduce the behavior
cdinto any local git repository whoseoriginremote is an Azure DevOps URL (e.g.https://org@dev.azure.com/org/project/_git/repo).copilot./mcp search.Failed to load registry: Error: Failed to fetch MCP registry policy: 400 Bad Request.cdoutside any git repository (e.g. home directory) and start a freshcopilotprocess./mcp searchagain → succeeds, returns all registry servers.Expected behavior
/mcp searchshould successfully fetch the registry policy regardless of the git remote host of the current working directory, or at minimum should not derive repo/org context from non-GitHub git remotes in a way that breaks the request.Additional context
/newinside the same running process does not recover it — only a full process relaunch outside a git-remote folder works.~/.copilot/mcp-config.jsonand connect fine from inside our Azure DevOps repos afterward — so the registry policy fetch specifically is what's broken, not general MCP connectivity.