I'm working on a Chrome extension (Manifest V3) that uses chrome.identity.launchWebAuthFlow() to implement "Sign in with Microsoft".

The OAuth flow behaves inconsistently after updating the extension, and I'm trying to understand why.

The Problem

After updating the extension code and having users replace their dist folder, when clicking "Sign in with Microsoft":

1. The Microsoft login popup opens.

2. Authentication succeeds

3. After successful login, the popup shows: "Authorization page could not be loaded"

4. The user is not logged into the extension.

Important Detail

• Reloading the extension from chrome://extensions

• Removing the extension and loading unpacked again

• Toggling Developer Mode off/on

• Clearing browsing data

Did NOT fix the issue

But:

Fully closing Chrome and reopening it fixed it immediately

After restarting Chrome, the OAuth flow works normally.

Context

• Manifest V3

• Background script implemented as a service worker

• Using chrome.identity.launchWebAuthFlow()

• Redirect URI is: https://.chromiumapp.org/callback

• The extension was recently updated (database schema change + code update)

• Users updated by replacing old dist folder with new one

• No Azure redirect URI changes between working and failing states

• Extension ID remained the same

OAuth Flow:

Extension → Backend /oauth/login → Microsoft Auth → Backend /oauth/callback 
→ Backend redirects to chrome-extension URL → launchWebAuthFlow callback

What Makes This Confusing

If it were:

• A redirect URI mismatch -> it shouldn't work after restart either

• A backend/database issue -> restart shouldn't fix it

• A permissions issue -> reloading extension should fix it

• Missing files in dist -> reinstalling should fix it

But only a full Chrome restart resolves it.

My Hypothesis

Since Manifest V3 uses ephemeral service workers instead of persistent background pages, I'm wondering if:

• The extension's service worker was in a stale runtime state

• The identity API redirect handler wasn't properly re-registered after reload

• Chrome was holding onto some internal OAuth/session state tied to the old version of the extension

• The redirect from Microsoft wasn't delivered to an active service worker

Is it expected that launchWebAuthFlow() can fail in this way if the service worker lifecycle is in an inconsistent state?

Has anyone seen OAuth redirects fail until a full browser restart?

Question

Why would a full Chrome restart fix an OAuth redirect failure in a Manifest V3 extension when reloading or reinstalling the extension does not?

Is this related to service worker lifecycle, identity API internals, or something else?

And more importantly: How can I prevent users from experiencing this when they update the extension? Instructing hundreds of users to restart Chrome after every update is not feasible.