Azure DevOps Services and Server · Pipelines agent, .NET tools, Azure CLI · Checked October 24, 2026

Azure DevOps: "VS30063: You are not authorized to access https://dev.azure.com."

Azure DevOps refused the credential that was sent, with HTTP 401. The message leaves out what you need to fix it: the address is often only https://dev.azure.com, not the organization, and it does not say whether the token had expired, came from another tenant, belonged to the wrong identity, or was missing. Public reports up to October 2026 quote it from the Azure Pipelines agent, .NET tools built on the Azure DevOps client libraries, the Azure CLI, Visual Studio Marketplace publishing and Azure DevOps's MCP server.

Where the text comes from

VS30063 is the Azure DevOps .NET client libraries' wording for a refused sign-in (VssUnauthorizedException). An analysis published in September 2026 in an open-source project found that the client turns a 401 that offers Basic authentication into VS30063 after quietly trying again, and does not pass the server's own sentence on.
What the server itself answered on October 24, 2026 to a private organization, with no token, an invalid personal access token and an invalid Bearer token alike (with the header X-TFS-FedAuthRedirect: Suppress): HTTP 401 and TF400813 for the anonymous ID aaaaaaaa-…. Without the header, a 302 to the sign-in page.
So the code tells you only that a credential was refused. Which one, and why, you find out below.

Find out what was refused

Which tenant is the organization in?
```
curl -sI https://dev.azure.com/<organization>
```
On October 24, 2026, two organizations answered 401 with the header X-VSS-ResourceTenant: <tenant ID>, and the same ID in WWW-Authenticate: Bearer authorization_uri=https://login.microsoftonline.com/<tenant ID>. Git Credential Manager reads the same two headers to decide where to sign in; in its code, an ID of all zeros means an organization backed by Microsoft accounts instead of Microsoft Entra.
Which tenant is your token from? For the Azure CLI: az account show --query tenantId. For a Microsoft Entra token, its tid claim. If the two IDs differ, that is the reason.
Who does the organization take the token for?
```
curl -u ':<token>' -H 'X-TFS-FedAuthRedirect: Suppress' \
  'https://dev.azure.com/<organization>/_apis/connectionData'
```
For a Microsoft Entra token, send -H 'Authorization: Bearer <token>' instead of -u. Read authenticatedUser.providerDisplayName: your name means the token is accepted; 401 with TF400813 means it is refused. On an organization with public projects, this answered 200 on October 24, 2026 even with an invalid token, with Anonymous as the name and the ID aaaaaaaa-…: read the name, not the status.

The causes public reports name

A token that expired during a long run. In an April 2026 report on the Azure Pipelines agent, a self-hosted job ran for more than four days with timeoutInMinutes: 0; after about 24 hours, log uploads and timeline updates failed with is not authorized. VS30063. Microsoft's answer: with 0, the job's access token gets a default lifetime instead of one that covers the timeout, so set timeoutInMinutes longer than the job (5760 for four days); the reporter confirmed that it worked. In a change to Microsoft's Docker agent sample (proposed in April, merged in August 2026), the script had fetched a Microsoft Entra token with a client ID and secret at start, and its cleanup hours or days later failed with VS30063; the change fetches a new token for the cleanup.
A valid token from another Microsoft Entra tenant. In a September 2026 report on Azure DevOps's hosted MCP server, guests in the organization's tenant got a token from their home tenant through some clients, and Azure DevOps refused it with VS30063; the same accounts worked from VS Code. An April 2026 pull request to Microsoft's npm sign-in helper (ado-npm-auth), still open in October, explains that its token tool asks Microsoft's own tenant by default, so organizations in other tenants get VS30063, and adds a tenant option.
The wrong identity, picked by a credential chain. In an April 2026 fix to a .NET build pipeline, a tool given the placeholder token unset fell back to DefaultAzureCredential, which on the build agent tried the agent's managed identity before the Azure CLI sign-in. That managed identity was not a member of the organization. The fix asks the Azure CLI for the token explicitly and passes it to the tool: az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 (the ID stands for Azure DevOps).
Publishing to the Visual Studio Marketplace. The address is then https://marketplace.visualstudio.com. An August 2026 report found that the token had to be made for All accessible organizations with the Marketplace (Manage) scope, and that a token missing either got only VS30063. Microsoft is retiring tokens for all organizations on Azure DevOps Services.
No credential at all. In an August 2026 report, a release job whose Marketplace token was deliberately not set failed with VS30063 on every run.
Azure DevOps Server or TFS on your own server. Microsoft's pipelines troubleshooting lists VS30063: You are not authorized to access http://<SERVER>:8080/tfs while configuring an agent, and says to make sure Anonymous Authentication is enabled for TFS in IIS on the server.

What to do

A personal access token: check its expiry under User settings, Personal access tokens, and create a new one for this organization with the scopes the tool needs.
Different tenants: get a token from the organization's tenant: az login --tenant <tenant ID>, or az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --tenant <tenant ID>. Tools that sign in for you often have a tenant option of their own.
In a pipeline: for a long job, set timeoutInMinutes longer than the job; in a script that keeps a token, fetch a new one before the step that uses it; with a credential chain, pass the token explicitly.

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 does not use the .NET client, so it reads what Azure DevOps itself answered: a refused personal access token reads as "Azure DevOps rejected the personal access token", with what to check and an Open settings link; a refused Azure CLI sign-in asks for az login with an account that can open this organization; and an Entra account the organization does not know yet is named as such (TF401444). From version 1.0.39, when Azure DevOps refuses an Azure CLI token from another Microsoft Entra tenant than the organization's (a guest account, for example), it asks the Azure CLI for a token of the organization's tenant and tries again, and names that tenant when the Azure CLI is not signed in there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps, Microsoft Entra and Visual Studio 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 or JetBrains.

More: git's "fatal: Authentication failed": the same refusal in git · TF400813: the token was not accepted · TF401444: the organization does not know the Entra account yet · 日本語