Git Credential Manager 3.0 and Azure Repos: what changed and how to go back
Git Credential Manager 3.0.0 came out on September 24, 2026, and its release notes list three changes for Azure Repos: it signs you in with OAuth tokens instead of creating personal access tokens, it uses your operating system's sign-in broker by default, and it signs in as its own Microsoft Entra application instead of Visual Studio's. IntelliJ IDEA, Rider and the other JetBrains IDEs run the Git installed on your computer, so this applies to Git in them too.
Do you have it
git credential-manager --version
| You use | Version on October 28, 2026 |
|---|---|
| Windows, the Git Credential Manager that came with Git for Windows | 2.x. The release notes up to Git for Windows 2.56.0(4) (October 26, 2026) last name v2.9.0 |
| Windows, Git Credential Manager installed on its own (for example for Bitbucket's November 30 change) | 3.0.x; a standalone install overrides the bundled one |
macOS, Homebrew (git-credential-manager cask) | 3.0.2 |
| Linux, .NET tool | The version you installed |
This is about Azure DevOps Services (dev.azure.com and *.visualstudio.com). For Azure DevOps Server, Git Credential Manager uses its generic provider (a comment in its Azure Repos code), so none of the three changes below apply.
What changed in 3.0
| Before 3.0 | From 3.0 | To go back |
|---|---|---|
| Created a personal access token for each organization | Uses Microsoft identity OAuth tokens, refreshed automatically while you use them and shared with Visual Studio | git config --global credential.azreposCredentialType pat |
| Broker only on Windows, and only if you turned it on | Broker by default on Windows, macOS and Linux where supported | git config --global credential.msauthUseBroker false |
| Signed in as the Visual Studio application | Signs in as Git Credential Manager's own Entra application | git config --global credential.azreposUseLegacyClientId true (meant as a temporary workaround) |
The same settings as environment variables: GCM_AZREPOS_CREDENTIALTYPE=pat, GCM_MSAUTH_USEBROKER=false, GCM_AZREPOS_USE_LEGACY_CLIENTID=true. Managed identity, service principal and workload identity federation sign-ins are not affected by the application change, the notes say.
If sign-in fails after the update
When the new application is refused as a client configuration error, Git Credential Manager prints:
Authentication using the new GCM Entra application failed. To retry this command with the legacy Entra application, set 'credential.azreposUseLegacyClientId' to 'true' in Git configuration.
It does not switch back by itself. Try one command with the old application:
git -c credential.azreposUseLegacyClientId=true fetch
If that works, the release notes ask you to report the original failure. The old application does not support the broker on macOS or Linux. If your tenant only lets listed applications sign in, the application IDs in Git Credential Manager's source are d735b71b-9eee-4a4f-ad23-421660877ba6 (new) and 872cd9fa-d31f-45e0-9eab-6e460a02d1f1 (legacy).
If you had set credential.msauthFlow=embedded, change it to auto, system or devicecode: the Windows embedded sign-in window was removed in 3.0.
Before the broker asks to enroll your device
The broker documentation warns about two things it does not control:
- Work or school account on a device the company does not manage (a personal computer, or a contractor's): the first sign-in can ask you to join Microsoft Entra ID or enroll in Intune, which can let the company's administrators monitor the device, install software and change settings. Ask them first, or turn the broker off before signing in.
- Personal Microsoft account on Windows with a local account: the Microsoft account can be linked to your local Windows account and change how you sign in to Windows.
On macOS the broker needs the Company Portal app and an enrolled device; on Linux the supported Intune setup, a GNOME desktop and Microsoft Edge, and it does not work headless or in WSL. Where it cannot be used, Git Credential Manager signs in through the browser or a device code.
Wrong account
With OAuth tokens Git Credential Manager remembers the account you chose for each organization (users and tokens):
git-credential-manager azure-repos list git-credential-manager azure-repos unbind <organization>
After unbind, the next Git command asks you to sign in again. If Azure DevOps answers TF401444, the organization does not know that account yet (what to check).
Scripts and older Windows
- Menus in the terminal now use the arrow keys instead of typed numbers, and
git credential-manager diagnoseprints a new format; scripts that drive either need updating. - Git Credential Manager 3 runs on Windows 10 or later and Windows Server 2016 or later. On Windows 7 and 8.x, 2.9.x gets security fixes only.
Azure DevOps pull requests in IntelliJ IDEA and Rider
Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It signs in to the Azure DevOps API with its own personal access token or with your Azure CLI sign-in (az login), not through Git Credential Manager; Git itself (pull, push, checkout) still uses your Git and its credential helper. The review inbox is free; voting, commenting and completing are Pro, with a 30-day trial.
Get it on JetBrains Marketplace
Azure DevOps, Visual Studio, Intune and Microsoft Entra are trademarks of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, JetBrains or the Git Credential Manager project.
More: Global personal access tokens are being retired · az repos pr and signing in to the Azure CLI · 日本語