Azure sign in torture

Visual Studio 2022 Community: Authentication Flow Regression / Account System Misdesign

Dear Microsoft,

I write this with the deepest possible respect, and with only the mildest desire to strike the Visual Studio account subsystem with a velvet-wrapped riding crop.

Visual Studio 2022 Community currently presents an Azure/Microsoft sign-in flow that is not merely inconvenient, but structurally hostile to local development after the recent update.

The problem is simple:

Visual Studio opens an authentication dialog. The user is asked to retrieve a verification code, often from email. The user switches to another application to obtain the code. The authentication dialog then becomes untouchable, backgrounded, stale, or simply dies. When the user somehow survives this ceremony and enters the code, Visual Studio may still forget the authenticated state and ask again on the next launch.

This is not authentication. This is a small escape room accidentally installed inside an IDE.

The deeper issue is architectural.

I am using Visual Studio locally. I am using GitHub. I am not asking for Azure integration. I am not deploying to Azure. I am not attempting to administer a tenant. I am not trying to perform a sacred cloud ritual under the full moon.

Yet Visual Studio behaves as if local IDE usage, Microsoft account identity, Azure, Azure DevOps, Entra, licensing, personalization, GitHub integration, and possibly the emotional well-being of Copilot all belong to one giant authentication casserole.

They do not.

A local IDE should remain usable when Azure is unavailable, unwanted, misconfigured, deleted, stale, cursed, or simply none of the IDE’s business.

The current behavior creates a false dependency:

“No Azure account? No stable Visual Studio session for you.”

That is an extraordinary position for a local development tool to take.

Visual Studio should clearly separate:

Local IDE use

Community license/account registration

GitHub authentication

Azure authentication

Azure DevOps authentication

Personalization/settings sync

Copilot or other optional cloud services

Each of these should fail independently.

If Azure sign-in fails, GitHub should still work. If GitHub sign-in fails, local projects should still work. If personalization sync fails, the editor should not behave as if the empire has collapsed. If an old Azure DevOps organization or Entra tenant reference is stale, Visual Studio should not keep summoning it like a Victorian ghost.

Most importantly, the authentication dialog must remain accessible while the user retrieves a code. If a sign-in flow requires switching applications, then switching applications cannot be allowed to break the sign-in flow. This is not an edge case. This is literally the workflow.

Kindly, with admiration for Visual Studio’s many excellent parts:

Stop making the IDE ask Azure questions when the user is trying to write code.

Local development must not be blocked by optional cloud identity plumbing.

Yours sincerely,

A developer who merely wanted to open a solution, not negotiate with a haunted tenant.