MCP Registry URL not retreived although properly set in Enterprise settings (Github Enterprise Managed Users)

[gitadminhmc]

Description
We are experiencing an issue with GitHub Copilot MCP in a brand‑new GitHub Enterprise Cloud tenant configured with Enterprise Managed Users (EMU) and EU data residency.

When configuring an MCP registry at the enterprise level (Enterprise → Copilot → AI controls → MCP), Copilot fails to load any MCP servers. In IDE developer tools, Copilot consistently receives a 404 response from the internal endpoint:

GET https://api.[tenant-name].ghe.com/copilot/mcp_registry
Because this endpoint returns 404, Copilot never retrieves the configured MCP registry URL and does not attempt to call the external registry (/v0.1/servers).

Key points

Enterprise is new (no migration from non‑EMU)
Enterprise Managed Users enabled
EU data residency
MCP enabled and configured at enterprise scope
MCP registry URL is valid and works in another non‑EMU / non‑EU enterprise
Toggling MCP settings and waiting for propagation does not resolve the issue
Behavior is consistent across multiple IDE clients

Expected behavior
/copilot/mcp_registry should return 200 with the effective MCP registry configuration once MCP is enabled at the enterprise level.

Actual behavior
Endpoint permanently returns 404, indicating the MCP policy object was never provisioned for this EU EMU enterprise.

• Copilot Chat Extension Version:
• VS Code Version: 1.111.0
• OS Version: W11
• Feature (e.g. agent/edit/ask mode): MCP
• Selected model (e.g. GPT 4.1, Claude 3.7 Sonnet): ALL

[gitadminhmc]

#295544 seems to be a similar issue, although our EMU tenant has data residency, and thus a different domain.

[sandy081]

Thank you for the detailed report. The 404 response from /copilot/mcp_registry suggests the MCP registry endpoint may not be provisioned for your Enterprise Managed Users (EMU) tenant with EU data residency. Could you please double-check with your GitHub Enterprise support contact why this endpoint returns a 404? Resolving the 404 on the server side would fix the issue on the VS Code side. This is likely a server-side configuration issue rather than a VS Code client bug.