Remote ADO MCP server with OAuth fails in v1.0.81 WAM implementation

[dak-cimpeco]

Describe the bug

When the CLI first loads, the Azure DevOps Remote MCP server fails to load, with a message stating that the MCP server "requires authentication". Using the suggested prompt "/mcp auth {server-name}" yields an "Authentication Failed" message:

It fails to fall back to the browser-based authentication that it had been using in the past on its own. That, I believe, is the bug. According to my research, the "Microsoft/azure-devops-mcp" project has a fallback for using browser-based authentication, which can be found in src/auth.ts lines 87-140.

In addition, the wording of the feature description in the release notes for 1.0.81 make it sound as if Copilot has the capability of falling back on its own:
(From https://github.com/github/copilot-cli/releases/tag/v1.0.81)
"Windows: remote MCP servers protected by Microsoft Entra ID can now sign in through the OS authentication broker (WAM), usually with no prompt at all. Other platforms, --device-code, and machines without the broker library keep the existing browser flow."
However, the wording of the error message (specifically the part about COPILOT_ENTRA_DISABLE_ONEAUTH) makes it sound as if I need to change some environment variable to sign in through the browser. I am wondering if something is being short-circuited before my Azure DevOps MCP Server can continue its authentication. I have replicated this using the standard remote server implementation outlined by the Readme on the Azure DevOps MCP server page: https://github.com/microsoft/azure-devops-mcp#remote-mcp-server-recommended

Affected version

1.0.81

Steps to reproduce the behavior

1. Open an instance of GitHub Copilot CLI v1.0.81 with the Azure DevOps Remote MCP server installed. This must be done without WAM authentication.
2. Follow the given instructions for authenticating with the Azure DevOps Remote MCP server.
3. If the following screenshot is seen, the bug has been replicated:

Expected behavior

Opening the GitHub Copilot CLI v1.0.81 successfully authenticates with the Azure DevOps Remote MCP server whether WAM authentication is available or not. Upon failing to retrieve the token through the WAM approach, the browser should be opened with an authentication prompt for the Azure DevOps Remote MCP server.

Additional context

This was done entirely on Windows 11. Behavior for other OSes has not been validated.
This was also done through Windows Terminal. Behavior for other terminal environments has not been validated.
No other remote MCP servers were tested. This may be a problem that extends to other remote MCP servers that allow for both WAM and browser-based authentication as well.

[MilkyWay008]

The v1.0.81 WAM path does exactly what you suspect: it short-circuits before the browser fallback, and the fallback in azure-devops-mcp src/auth.ts never gets a chance to run because the CLI's OneAuth wrapper reports failure first. Quick test: set COPILOT_ENTRA_DISABLE_ONEAUTH=1 (the env var the error message itself hints at) and restart, that forces the old device-code/browser flow and sidesteps WAM entirely. If that clears it, the bug is squarely in the 1.0.81 WAM integration, not the MCP server. Rollback to 1.0.80 also works as a stopgap since the browser flow was intact there. oh, btw, I built a portable Hermes OTG and I run it on USB as my rescue agent; super handy doing quick diagnose & fix, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG