Windows: MCP Entra sign-in fails with "this server's advertised scopes could not be safely validated for the account broker"

[markwtwjeffries]

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

1. Configure an MCP server pointing at  https://mcp.dev.azure.com/{org}  (type  http ) via a Copilot CLI plugin.
2. Start a new Copilot CLI session.
3. Run  /mcp auth ado  (or whatever the server is named).
4. Expected: Windows account picker / browser OAuth dialog opens for Entra sign-in.
5. Actual: Dialog never appears; command fails instantly with the "advertised scopes could not be safely validated for the account broker" error.

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

• This started suddenly with no local configuration changes on the user's part. CLI terminals that were already open and authenticated from the day before continue to work fine (silent token renewal via  acquireTokenSilent  still succeeds). Only brand-new sessions attempting a fresh interactive sign-in ( acquireTokenInteractive ) hit this error — suggesting the issue is specific to the interactive WAM/native-broker code path, not silent renewal.
• Deleting all cached OAuth token files under  %USERPROFILE%.copilot\mcp-oauth-config*.tokens.json  for this server did not resolve the issue.
• The exact error string does not appear anywhere in the CLI's JS bundle ( cli-main.js ), indicating it originates from the native Windows MSAL broker/WAM component ( msalruntime.dll  /  msal-node-runtime.node ), which performs its own scope-safety validation before invoking the Windows account picker.
• Reproduces identically on CLI 1.0.92 (stable) and 1.0.93-2 (prerelease), which rules out a simple JS-level regression introduced between those versions.
  was added, ~1.0.81) that is only now being triggered.
• The CLI's own changelog (bundled  changelog.json ) mentions related recent changes: "Entra-protected MCP servers can silently renew access-token-only credentials" and "Entra sign-in falls back to browser auth when no broker is available" — but in this case it is not falling back to browser auth; it hard-fails instead.

[JoshEbersol]

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 broker

Regression: On 1.0.91 the same config and machine logged Entra scope binding validation bypassed for an unbound scope and 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/.default is on the same origin as the server URL https://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 advertise api://<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.

[davidgourde]

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, endpoint https://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 broker

Over 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_scopes workaround 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.