Passkey support completely broken when 1Password extension is co-installed (blocking for users in enforced work environments)

Steps To Reproduce

1. On macOS (also reproduced on Linux), use Google Chrome 148.0.7778.179.
2. Install the Bitwarden browser extension 2026.4.1.
3. Install the 1Password browser extension alongside it (in many corporate environments this is mandated by policy and cannot be disabled by the end user).
4. Have a passkey stored in Bitwarden for a site that supports passkeys (e.g., github.com).
5. Trigger a passkey flow on that site (e.g., GitHub sudo-mode re-auth, or "Sign in with a passkey").

Expected Result

Bitwarden either intercepts the WebAuthn request and presents its own passkey picker, or — when another passkey provider is also registered — the browser shows a chooser that allows the user to pick Bitwarden. The Bitwarden-stored passkey should remain usable.

Actual Result

Chrome's native passkey dialog appears and routes the request to a non-Bitwarden provider (1Password / iCloud Keychain). Bitwarden never gets a chance to surface its passkey, even though the credential exists in the Bitwarden vault and Bitwarden is configured as the default password manager in Chrome. Passkeys stored in Bitwarden become effectively unusable for as long as the 1Password extension is enabled.

Disabling the 1Password extension restores Bitwarden's passkey interception. For users whose organizations mandate 1Password via MDM / work policy, there is no workaround — Bitwarden passkeys cannot be used at all.

Screenshots or Videos

No response

Additional Context

This is a follow-up to #20743, which documents the broader Chrome 146+ passkey-interception regression. The comment thread (see https://github.com/bitwarden/clients/issues/20743#issuecomment-4587926129 and surrounding discussion) makes it clear that the failure mode is now reliably tied to having a second passkey-capable extension (1Password) installed.

Key points that justify a separate report:

• This is not just "two password managers don't coexist nicely" — it is a complete breakage of Bitwarden passkey functionality, not a degraded UX.
• It affects users who cannot uninstall or disable 1Password (enforced work profiles, MDM-managed browsers, locked corporate extensions).
• It is reproducible across operating systems (macOS, Linux, Windows reports also in the thread) and is not limited to a single Chrome/Bitwarden version combination.
• A community fix has been proposed in #20849 which migrates Bitwarden to Chrome's official chrome.webAuthenticationProxy API (available since Chrome 115). Adopting that API would let Chrome route WebAuthn requests to Bitwarden deterministically instead of relying on content-script interception that loses the race to 1Password / the native picker.
• 1Password support has reportedly told affected users that the responsibility lies with Bitwarden, so a coordinated fix on the Bitwarden side is needed.

Related: #20743, #20849, #14720.

Operating System

macOS, Linux, Windows

Operating System Version

macOS 15.7.3 (24G419) — also reproduced on macOS 26.3.1, Linux, and Windows 11 per #20743 thread

Web Browser

Chrome

Browser Version

Google Chrome 148.0.7778.179 (Official Build, arm64)

Environment Versions

Extension 2026.4.1 (bitwarden.com and bitwarden.eu both affected)

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.