Why does Visual Studio keep using stale permissions after my Azure role changes?

Short answer

Visual Studio 2022 reuses cached Microsoft Entra ID access and refresh tokens for Azure and Azure DevOps. Role assignments are encoded in the token at issuance time. Azure AD does not push revocation to the client, so VS continues to use the existing token until it expires or is explicitly refreshed. That is why newly granted roles can be invisible and revoked roles can linger.

Confirmed behavior

• Token storage. Visual Studio stores Azure AD tokens via the Account Settings manager. On Windows the cache lives under %APPDATA%\Microsoft\VisualStudio\\VSCommon\AccountsControl\AccessTokens and is tied to the Windows user profile. The Azure Account extension and the built-in Azure DevOps sign-in share this broker.
• Token lifetimes. Access tokens are typically short lived, commonly ~1 hour. Refresh tokens can be valid for days to 90 days depending on tenant policy and conditional access. VS will silently use a refresh token to obtain a new access token without prompting you.
• Components that rely on the cached token. Azure Account window, Cloud Explorer, Connected Services, and Azure SDK calls from the IDE all use the cached token from the broker. Azure DevOps Team Explorer and Git connections use a separate Azure DevOps PAT / Entra token cache managed by the same Account Settings system. Azure service connections inside a pipeline are not affected by your local VS cache; they use the service connection credentials stored in Azure DevOps.

Likely explanation for the delay

When an admin changes Azure RBAC or Azure DevOps permissions, the change is effective at the identity provider immediately, but Visual Studio does not query Entra ID on every operation. It only acquires a fresh token when:

• the current access token expires,
• the refresh token is invalidated by a password change, MFA reset, admin forced sign-out, or conditional access policy,
• you sign out and sign back in, or
• a VS component explicitly requests interactive authentication.

Because of that, the stale-permission window is bounded by the token lifetime, not by the role change time. This is standard OAuth2 behavior, not a Visual Studio bug.

What actually triggers re-authentication

Re-authentication prompts appear when the broker cannot obtain a valid access token silently. That happens on token expiry, refresh token revocation, or when you open an account that has no valid cached token. A normal role change alone does not trigger a prompt.

Does sign-out/sign-in fully clear the cache?

Signing out of the account in Visual Studio > File > Account Settings > Sign out removes the tokens for that account from the local cache and forces a fresh interactive login on next use. That reliably picks up current role assignments. Residual account metadata may remain in VS settings, but it does not carry token validity.

Practical steps for this case

1. Identify the scope. Confirm whether the stale behavior is in Cloud Explorer / Azure Account or in Azure DevOps Team Explorer / Git. They use different permission sets.
2. Force a fresh token. In Visual Studio go to File > Account Settings, select the Microsoft Entra account and choose Sign out, then Sign in again. Restart Visual Studio after sign-in.
3. Optional verification. After sign-in, open Cloud Explorer and check resource visibility, or attempt an operation that previously failed/succeeded. If you need a quicker test without sign-out, wait for the access token lifetime to elapse, typically about an hour, and perform the operation again.

Note: Token lifetimes are tenant controlled. If your organization enforces short-lived access tokens via conditional access, the stale window will be smaller. Clearing the AccessTokens folder manually can affect other VS-integrated services that rely on SSO; sign-out/sign-in is the safer method.

One diagnostic detail that changes the recommendation: Are you seeing the stale permissions in Azure resources via Cloud Explorer / Azure Account, or in Azure DevOps organization access via Team Explorer / service connections? Azure DevOps permissions are evaluated separately from Azure RBAC and may require a different refresh path.