Azure DevOps Services and Server · git over HTTPS · Checked October 28, 2026

Azure DevOps: "fatal: Authentication failed for 'https://dev.azure.com/…'"

Git prints this when Azure DevOps answered HTTP 401 to the password git sent: for Azure Repos, a personal access token (PAT), or the OAuth token Git Credential Manager signs in with. Azure DevOps does not say why it refused it; the answer is empty. So look at the token itself: it expired, was revoked, became inactive, was made for another organization or lacks the Code scope, or the account lost access.

The whole answer

What dev.azure.com answered on October 28, 2026 to a token it did not take, for a repository in an organization that exists:

git ls-remote https://dev.azure.com/<organization>/<project>/_git/<repository>
fatal: Authentication failed for 'https://dev.azure.com/<organization>/<project>/_git/<repository>/'

The HTTP answer behind it:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="https://tfsprod….app.visualstudio.com/"
Content-Length: 0

What else we saw that day:

No remote: line and no TF number. Unlike TF401019 (a repository the account cannot see) or TF402455 (a protected branch), nothing in the message tells the causes apart.
An organization that does not exist gives another message: fatal: repository '…' not found (HTTP 404), with or without a token. "Authentication failed" means the organization is there.
A public repository is read without asking. git ls-remote listed a public repository's branches even with a made-up token in the URL: git sends the password only when the server asks for one.
With no credentials at all, git asks for a user name instead; in a script with prompts turned off that is fatal: could not read Username for '…': terminal prompts disabled.

Why Azure DevOps refuses a token

Microsoft's Use personal access tokens (updated September 21, 2026) answers "Why did my PAT stop working?" with this list:

It expired. Azure DevOps sends a notification before a PAT expires. An expired PAT cannot be regenerated: create a new one.
It was revoked: by you, by an administrator, or by Azure DevOps itself, which scans public GitHub repositories for leaked PATs and revokes the ones it finds unless the tenant's policy turns that off.
It became inactive. In an organization backed by Microsoft Entra ID, Microsoft says to sign in with a new PAT within 90 days or it becomes inactive, and Conditional Access may require signing in more often: sign in to Azure DevOps in the browser, complete the whole prompt, and try again.
Its scopes are not enough. For git, the PAT needs the Code scope: Read to clone and fetch, Read & write to push.
The user's access changed. When the account is disabled or removed from the organization, its PATs no longer reach that organization; if access comes back, a PAT that has not expired or been revoked works again.

Two more that look the same from git: a PAT is made for one organization, and the organization is the first part after dev.azure.com/ in the remote URL (git remote -v); and PATs made for "All accessible organizations" are being retired (the retirement and its postponed date). On Azure DevOps Server, Microsoft adds that IIS Basic Authentication prevents PAT authentication and should stay disabled.

Find which one

Your token list. In Azure DevOps, User settings › Personal access tokens shows each PAT's status, organization, scopes and expiration. A PAT named git: https://dev.azure.com/<organization> on <computer> was made by Git Credential Manager when git first connected.
The audit log, for an organization administrator: Organization settings › Auditing, filtered for Token.PatExpiredEvent, Token.PatRevokeEvent, Token.PatSystemRevokeEvent (revoked by Azure DevOps) and Token.PatPublicDiscoveryEvent (found in a public repository). Microsoft keeps audit events for 90 days and does not log when a PAT was used.
The account. Open the repository in the browser with the same account. If Azure DevOps asks you to sign in first, see TF401444.

When git keeps sending the old token

After a 401, git tells its credential helper to forget the password and asks again: in IntelliJ IDEA and Rider through the IDE's login window, on the command line through the credential helper or the terminal. Enter the new PAT as the password; Microsoft says the user name can be empty.
If the old PAT is written in the remote URL itself, git keeps using it: Microsoft advises against PATs in remote URLs. Set the URL without it (git remote set-url origin https://dev.azure.com/<organization>/<project>/_git/<repository>) and let the credential helper hold the token.
Git Credential Manager 3.0 signs in to Azure Repos with your Microsoft account in the browser and keeps OAuth tokens, not PATs. If it signs in with the wrong account, or warns that "Authentication using the new GCM Entra application failed", see Git Credential Manager 3.0 and Azure Repos (git credential-manager azure-repos list and unbind, and the one-off retry with the legacy app).
Git over SSH does not use the PAT (what goes wrong over SSH instead).

Azure DevOps pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, signs in to the REST API with its own personal access token, kept in the IDE's password safe apart from git's, or with the Azure CLI. When Azure DevOps refuses the token, it says so and names the usual reasons: expired, without the Code scope, or made for "All accessible organizations". The review inbox is free; voting, commenting and completing are Pro (US$1 a month, with a 30-day trial).

Get it on JetBrains Marketplace

Azure DevOps is a trademark of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: "VS30063: You are not authorized to access https://dev.azure.com" (the same refusal in .NET tools) · "TF400813: The user … is not authorized" · 日本語