Cloud agent: MCP registry policy fetch fails with 401/403 on GHEC data residency, silently blocking all user-configured MCP servers

Describe the bug

Summary

On a GitHub Enterprise Cloud with data residency instance (<tenant>.ghe.com), every user-configured MCP server is silently dropped from Copilot cloud agent sessions. Only the platform defaults (github-mcp-server, playwright) reach the model. The cause is the registry-policy fetch failing with 401/403 and falling into the fail-closed path — the same defect as #2498, where only the 404 leg was fixed.

This is the same fail-closed family as #2498, #2552, #2567, #4346 and #4349, but reached through the cloud agent, where nothing is surfaced to the user at all.

Environment

• Surface: Copilot cloud agent (not the local CLI, not an IDE)
• Host: GitHub Enterprise Cloud with data residency, <tenant>.ghe.com
• Two MCP servers configured in repo Settings → Copilot → MCP servers: one remote http, one local (stdio). Both valid per the documented schema, both with explicit tools lists.
• Enterprise MCP registry: none configured. GET /copilot/mcp_registry (user PAT) returns {"mcp_registries":[{"url":"","registry_access":"allow_all",...}]}
• GET /copilot_internal/user reports is_mcp_enabled: true, copilot_plan: "enterprise"

What happens

From the CLI's own log inside the session (~/.copilot/logs/process-*.log):

[ERROR]   Failed to validate SDK token (401): GitHub returned: Bad credentials
[WARNING] session.gitHubAuth.setCredentials: failed to re-resolve copilotUser for token
          credential; token swap applied, plan/quota/billing metadata degraded:
          Failed to fetch Copilot user info: 401 Unauthorized: {"message":"Bad credentials"}
[WARNING] Failed to fetch MCP registry policy: 401 Unauthorized.
          Non-default MCP servers will be blocked until the policy can be fetched.
[ERROR]   MCP server "<remote-server>" filtered: Could not verify server against any configured registry
[ERROR]   MCP server "<local-server>"  filtered: Could not verify server against any configured registry
[ERROR]   Using deferred connection for default Playwright server

Probing the endpoint from inside the session with every credential present (GITHUB_COPILOT_API_TOKEN, GITHUB_TOKEN, COPILOT_SDK_AUTH_TOKEN, …): 403 on api.<tenant>.ghe.com/copilot/mcp_registry, 401 on api.github.com/copilot/mcp_registry. The same endpoint returns 200 allow_all to a normal user PAT.

Why this is a bug, not policy

1. 404 is tolerated, 401/403 is not. The client special-cases a 404 as "no registry configured, allow all", but any other failure throws into the fail-closed catch that blocks every server without isDefaultServer. A tenant with no registry configured is therefore treated as if it prohibited everything, purely because its endpoint answers 403 instead of 404. #2498 fixed the 404 leg; the auth-failure leg has the identical consequence.
2. This filter is documented as not applying to the cloud agent. Per the MCP-management support matrix, "Registry display" and "Allowlist enforcement" are Not supported for Copilot cloud agent, and the enterprise docs state private MCP registries "apply to Copilot CLI and IDEs, but not to cloud agents that run on GitHub." It is nonetheless the filter rejecting these servers.
3. The root credential failure looks host-related. Bad credentials is what api.github.com returns for a token minted by another host, which suggests the SDK-token validation and/or the policy fetch resolves to public github.com rather than the data-residency tenant.

Everything upstream is healthy

Verified in-session, so the failure is purely in the policy filter:

• GET /repos/{owner}/{repo}/copilot/cloud-agent/configuration returns both servers as stored.
• The Start MCP Servers step succeeds; the local MCP proxy serves all servers' tools (GET 127.0.0.1:2301/tools — 62 tools, including all of both user servers').
• The stdio server's initialize/tools/list handshake works when driven by hand on the runner.
• COPILOT_MCP_ENABLED=true, GITHUB_COPILOT_3P_MCP_ENABLED=true, COPILOT_PERMISSION_MODE=allow_all.

Impact

Nothing is surfaced. No failed step, no warning in the pull request, no line in the session transcript. The messages above exist only in the CLI's private log inside the ephemeral runner. In our case a Microsoft Learn MCP server had been silently dead in every cloud-agent session for an unknown period, and we only found it while investigating a second server. Unlike the local CLI — where --log-level debug reveals it — cloud-agent users have no way to observe this.

Reproduced across three different agent runtime builds.

Suggested fix

Either (or both):

1. Treat an auth failure (401/403) on the registry-policy fetch the same as 404 when no registry is configured for the tenant — i.e. extend #2498's fix beyond 404.
2. Fix host/token resolution so the policy endpoint authenticates on data-residency instances.

Additionally: surface a blocked-server warning on the pull request, the way firewall blocks already are. A silent drop is indistinguishable from the agent choosing not to use a tool.

Ruled out

MCP servers in Copilot policy (enabled), registry allowlist (allow_all), custom agent tools: filter (none present), server transport (remote HTTP and local stdio fail identically), config schema (validated by the Settings UI), and any client-side override (no env var, CLI flag, or settings key reaches the gate; isDefaultServer is rejected by the Settings schema validator).

Affected version

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

Bắt đầu bằng cách lần theo việc lấy chính sách registry MCP và hoạt động lọc fail-closed phía sau các lệnh gọi GET /copilot/mcp_registry, sử dụng nhật ký tiến trình CLI và endpoint cấu hình cloud-agent làm các điểm bắt đầu. So sánh cách xử lý 401/403 với hành vi 404 hiện có và xác minh việc phân giải host của credential; được xem là hoàn tất khi các server đã cấu hình không bị âm thầm loại bỏ trên các tenant có yêu cầu lưu trú dữ liệu và các server bị chặn tạo ra cảnh báo hiển thị được.