Repository navigation
Windows: MCP Entra sign-in fails with "this server's advertised scopes could not be safely validated for the account broker" #5068
Description
Activity
Same issue here on 1.0.92 (Windows, Entra broker). With debug logging, the logs show where the error comes from and suggest a workaround.
Where the error comes from: the CLI's own Rust MCP OAuth layer, not
msalruntime.dll:[WARNING] [rust:mcp_engine::oauth_entra] Entra scope binding (strict, the default) rejected a scope whose resource does not bind to this MCP server; set COPILOT_ENTRA_ONEAUTH_SCOPE_BINDING_MODE=allow_unbound_scopes to permit unbound resource scopes for a trusted server {"server_url":"https://mcp.dev.azure.com/<org>","rejected_scope":"https://mcp.dev.azure.com/.default"} [WARNING] [rust:mcp_engine::oauth_entra] Entra fast path refused scopes that failed validation or are not bound to the MCP server's own origin [WARNING] [rust:mcp_engine::oauth_flow] Entra broker cannot serve this server; not falling back to the browser [ERROR] OAuth authentication failed for ado: MCPOAuthError: Microsoft Entra sign-in for https://mcp.dev.azure.com/<org> failed: this server's advertised scopes could not be safely validated for the account brokerRegression: On 1.0.91 the same config and machine logged
Entra scope binding validation bypassed for an unbound scopeand auth succeeded. On 1.0.92 the default is strict, and the rejection is fatal with no browser fallback.Looks like a bug in the binding check itself:
https://mcp.dev.azure.com/.defaultis on the same origin as the server URLhttps://mcp.dev.azure.com/<org>, so it should count as bound. The check appears to compare against the path-qualified URL, not the origin. Servers that advertiseapi://<app-id>/...scopes fail the same way.Workaround: set this user env var and start a new terminal:
[Environment]::SetEnvironmentVariable('COPILOT_ENTRA_ONEAUTH_SCOPE_BINDING_MODE','allow_unbound_scopes','User')
Note that this relaxes the scope-binding protection for all MCP servers, not just ADO - so it should be removed once there's a fix.
Reacted by Sebastian, pmamcarz and David Gourde- addedarea:mcpMCP server configuration, discovery, connectivity, OAuth, policy, and registryMCP server configuration, discovery, connectivity, OAuth, policy, and registryarea:platform-windowsWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows TerminalWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows Terminaland removed
on Oct 7, 2026 I’m seeing the same error in GitHub Copilot Desktop on Windows, not just standalone CLI. The CLI runtime in my app session is 1.0.93-1.
In Customize, clicking Sign in for the hosted Azure DevOps MCP server (
ado-remote-mcp, endpointhttps://mcp.dev.azure.com/<org>) fails with:Authentication failed ado-remote-mcp: RPC error -32603: Request session.mcp.oauth.login failed with message: Microsoft Entra sign-in for https://mcp.dev.azure.com/<org> failed: this server's advertised scopes could not be safely validated for the account brokerOver the last couple of days, I’ve also seen multiple MCP servers repeatedly lose authentication or refresh/reconnect, enough to interrupt my work. I don’t yet know whether that recurring behavior is related to this specific sign-in failure.
I have not applied the
allow_unbound_scopesworkaround because it relaxes scope validation beyond this one server. Please include the Desktop authentication path when investigating this issue, and provide a supported workaround that preserves scope validation.
Describe the bug
On Windows, authenticating to an Entra ID–protected MCP server (Microsoft's hosted Azure DevOps MCP server, https://mcp.dev.azure.com/{org} , server type http ) fails on every fresh interactive sign-in attempt with:
Authentication failed: MCPOAuthError: Microsoft Entra sign-in for https://mcp.dev.azure.com/{org} failed: this server's advertised scopes could not be safely validated for the account broker
/mcp auth does not open the login/account-picker dialog at all — it fails immediately with the above error.
Affected version
GitHub Copilot CLI 1.0.93-2
Steps to reproduce the behavior
Expected behavior
when the native broker cannot safely validate a server's advertised scopes, the CLI should fall back to standard browser-based OAuth instead of failing outright, consistent with the documented fallback behavior for "no broker available."
Additional context
was added, ~1.0.81) that is only now being triggered.