Code change:
private async addOrUpdateAccount(providerId: string, account: AuthenticationSessionAccount): Promise<void> { let accounts = this.groupedAccounts.get(providerId); <del> if (accounts) { const existingAccount = accounts.find(a => a.id === account.id); if (existingAccount) { // Update the label if it has changed if (existingAccount.label !== account.label) { existingAccount.label = account.label; } return; } } else { </del> <ins> if (!accounts) { </ins> accounts = []; this.groupedAccounts.set(providerId, accounts); } const sessionFromEmbedder = await this.sessionFromEmbedder.value; <del> // If the session stored from the embedder allows sign out, then we can treat it and all others as sign out-able let canSignOut = !!sessionFromEmbedder?.canSignOut; if (!canSignOut) { if (sessionFromEmbedder?.id) { const sessions = (await this.authenticationService.getSessions(providerId)).filter(s => s.account.id === account.id); canSignOut = !sessions.some(s => s.id === sessionFromEmbedder.id); } else { // The default if we don't have a session from the embedder is to allow sign out canSignOut = true; } </del> <ins> let canSignOut = true; if ( sessionFromEmbedder												// if we have a session from the embedder && !sessionFromEmbedder.canSignOut								// and that session says we can't sign out && (await this.authenticationService.getSessions(providerId))	// and that session is associated with the account we are adding/updating .some(s => s.id === sessionFromEmbedder.id && s.account.id === account.id ) ) { canSignOut = false; </ins> } <del> accounts.push({ ...account, canSignOut }); </del> <ins> const existingAccount = accounts.find(a => a.label === account.label); if (existingAccount) { // if we have an existing account and we discover that we // can't sign out of it, update the account to mark it as "can't sign out" if (!canSignOut) { existingAccount.canSignOut = canSignOut; } } else { accounts.push({ ...account, canSignOut }); } </ins> } private removeAccount(providerId: string, account: AuthenticationSessionAccount): void {

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No. Related to extension api <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.79.0-insider OS Version: Macintosh; Intel Mac OS X 1340 Getting a session for a Microsoft account for the default tenant, and also getting a session for the account but for a specific tenant results in two items for the same account appearing in the Accounts menu. <img width="546" alt="image" src=""Steps to Reproduce: First call with the following scopes: . And another call to with these scopes: I want to point out that the account objects on the returned sessions are actually different: <br<details<summaryMicrosoft Authentication provider logs</summary<p</p</detailscc:
These accounts aren't duplicate, they are sessions that exist for each signed-in tenant. I think the best solution would be to change the account label to . This would match what the Azure portal does. <img width="201" alt="image" src=""I think this is an important change to make because this really doesn't look good and is confusing to users. Especially when users are trying to sign out. The screenshot below is after I sign in with a single Microsoft account that has 4 tenants. Having 4 tenants is not uncommon. <img width="515" alt="image" src=""
Yeah this goes back to that "technically they're different accounts because they're in different tenants" thing. I'm inclined to agree with you and dedupe per-label.
Although that would present better, I think deduping on the label wouldn't be great unless you made the label more standard across tenants.