Activity

1. github-actions

   added

   triage

   on Aug 4, 2026
2. copilot-cli-release-app

   added

   area:enterpriseGitHub Enterprise (GHE/GHES) support, org policies, and enterprise settingsGitHub Enterprise (GHE/GHES) support, org policies, and enterprise settings

   area:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registryMCP server configuration, discovery, connectivity, OAuth, policy, and registry

   area:networkingProxy, SSL/TLS, certificates, corporate environments, and connectivity issuesProxy, SSL/TLS, certificates, corporate environments, and connectivity issues

   on Aug 11, 2026
3. copilot-cli-release-app

   added the

   Bug

   issue type on Aug 11, 2026
4. copilot-cli-release-app

   removed

   triage

   on Aug 11, 2026
5. nicodemuz commented on Sep 29, 2026

   

   nicodemuz

   on Sep 29, 2026

   More actions

   I'm encountering the same issue. Bug report by Copilot CLI below:

   Enterprise MCP registry unreachable due to TLS 1.2-only server + rustls TLS 1.3 requirement → CLI fails closed and blocks all custom MCP servers

   Summary

   Our organization enforces registry_access: "registry_only" via an Azure API Center-hosted MCP registry. The registry endpoint only supports TLS 1.2. Since Copilot CLI moved MCP registry validation to the native Rust HTTP client (reqwest + rustls/rustls-platform-verifier), starting around v1.0.78, the registry handshake fails outright (TLS 1.3 is required/preferred by the client), and the CLI fails closed — blocking all custom MCP servers, even ones that are correctly listed in the registry and would otherwise connect successfully.

   This looks like the same class of bug as #4364 (rustls being stricter than the previous Node/JS TLS stack, causing a working registry to be treated as unreachable), but triggered by TLS protocol version mismatch rather than private CA cert trust. Filing this as a related report / additional data point in case it's a distinct root cause under the same symptom.

   Environment

   • Copilot CLI version: 1.0.89 (also reproduced on 1.0.85–1.0.88)
   • OS: macOS (Apple Silicon, arm64)
   • Install method: standalone self-updating binary (~/.local/bin/copilot), not Homebrew/npm
   • Org MCP registry: Azure API Center-hosted, registry_access: "registry_only" policy (confirmed via gh api /copilot/mcp_registry)
   • Registry host: <redacted>.data.<region>.azure-apicenter.ms (Azure API Center MCP registry, workspace default)

   Steps to Reproduce

   1. Configure an enterprise/org Copilot policy with registry_access: "registry_only" pointing to an Azure API Center MCP registry that only supports TLS 1.2 (no TLS 1.3 listener/cipher suite configured).
   2. Add one or more MCP servers locally in ~/.copilot/mcp-config.json that are also present in the registry (e.g. an http-type remote server).
   3. Launch copilot.
   4. Observe the startup banner:

      2 MCP servers were blocked by policy: '<server-a>', '<server-b>'
      

   5. Run /mcp show → Online tab. Observe:

      Failed to load online results: Error: HTTP request failed: error sending request for url
      (https://<registry-host>/workspaces/default/v0.1/servers?limit=30)
      

   Root Cause Analysis

   Verified directly with openssl s_client against the registry host:

   $ openssl s_client -connect <registry-host>:443 -tls1_3
   ...
   SSL alert number 40
   140704... SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
   
   $ openssl s_client -connect <registry-host>:443 -tls1_2
   ...
   New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
   Verify return code: 0 (ok)
   

   The registry server only accepts TLS 1.2.

   curl against the same URL succeeds (HTTP 200, valid JSON) from multiple machines/networks, because curl's TLS stack negotiates down to TLS 1.2 transparently. This makes the issue easy to misdiagnose as a network/proxy/DNS/RBAC problem, since manual connectivity checks all look "clean."

   The Copilot CLI's registry-fetch request (used both for the startup policy check and the /mcp show → Online tab) does not appear to negotiate down the same way, and the request fails. The CLI then fails closed, blocking all locally configured MCP servers that aren't already trusted/cached — rather than surfacing a TLS/connectivity error or failing open.

   Expected Behavior

   • The CLI's HTTP client should support the same TLS version range as common HTTP clients (curl, browsers), i.e. negotiate TLS 1.2 when the server doesn't support 1.3, rather than hard-failing.
   • If the registry truly cannot be reached, the CLI should surface a clear, actionable error (e.g. "Failed to reach MCP registry: TLS handshake failed") instead of a generic "blocked by policy" banner that gives no indication of the underlying transport failure.
   • Ideally, failure to validate against the registry should not silently block servers that are otherwise configured correctly and reachable — or at minimum should be distinguishable from an explicit deny-by-policy block.

   Additional Notes

   • Both blocked servers in our case (atlassian-mcp-v2-auth, a remote http-type server, and playwright, a local npx-launched server) actually connect and authenticate successfully at the transport level per session logs (Successfully authenticated with ..., Service initialized as client), despite being reported as "blocked by policy" in the startup banner. This suggests the banner/registry-check failure is somewhat decoupled from actual server connectivity, but still degrades the UX and (per /mcp show) prevents browsing the org's allowed server catalog.
   • We are attempting to verify whether this regression was introduced around v1.0.78 (when registry validation reportedly moved from a Node/JS-based TLS client to the native Rust/reqwest+rustls client) by testing against an older CLI build; will update this issue with results.
   • Workaround considered: none currently available on the client side; the real fix is likely either (a) enabling TLS 1.3 on the registry endpoint (Azure API Center-side, may not be configurable by us), or (b) the CLI's HTTP client negotiating TLS 1.2 as a fallback like other clients do.

   Ask

   • Can the CLI's registry-fetch HTTP client be configured to allow TLS 1.2 as a fallback (matching typical HTTP client behavior), or at least surface the specific TLS error instead of a generic policy-block message?
   • Is this considered the same root cause as Enterprise MCP registry unreachable on macOS: rustls rejects private CA cert (Apple -67901), fail-closed blocks all MCP #4364, or should it be tracked separately given it's a TLS protocol version issue rather than a CA trust issue?

   👍React with 👍1Reacted by Julien Landuré