Disable passkey autofill popup in browser VMs

[masnwilliams]

Summary

• Disables Chrome's WebAuthn Conditional UI (WebAuthenticationConditionalUI feature flag) which shows "Use passkey from another device" overlays on login form inputs
• This popup blocks CUA click actions during managed auth flows (e.g. Amazon login)
• Headless: added to the existing --disable-features list in wrapper.sh
• Headful: added to chromium-launcher hardcoded args (headful doesn't set CHROMIUM_FLAGS, so this is the only --disable-features it gets)

Follows the same pattern as the existing PasswordManagerEnabled: false, AutofillAddressEnabled: false, and AutofillCreditCardEnabled: false policies in policy.json — this just covers the passkey variant that wasn't disabled yet.

Test plan

• Build headless image and verify no passkey popup appears on Amazon login
• Build headful image and verify no passkey popup appears on Amazon login

Made with Cursor

---

Note

Medium Risk
Adds a Chromium feature-disable flag that changes WebAuthn/passkey UI behavior; this could impact sites that rely on conditional passkey prompts even though it reduces automation-blocking overlays.

Overview
Disables Chrome’s WebAuthn Conditional UI (the passkey autofill/"use passkey from another device" overlay) across browser VMs.

Headless images now include WebAuthenticationConditionalUI in the existing --disable-features list in wrapper.sh, and headful launches add --disable-features=WebAuthenticationConditionalUI as a hardcoded arg in chromium-launcher so the popup can’t block managed auth flows.

^{Written by Cursor Bugbot for commit 792212e. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Hardcoded --disable-features silently overridden by later flag

Medium Severity

Chromium uses last-one-wins semantics for duplicate --disable-features flags. The hardcoded --disable-features=WebAuthenticationConditionalUI in chromiumArgs is placed before final is appended (line 70), so any --disable-features entry in final silently overrides it. In headless mode this happens every time — wrapper.sh's comprehensive --disable-features list lands in final and replaces the hardcoded one. It works today only because wrapper.sh independently added WebAuthenticationConditionalUI. If the two lists ever diverge, or if headful runtime flags introduce a --disable-features, the hardcoded flag labeled "flags we send no matter what" will have no effect.

Additional Locations (1)

• images/chromium-headless/image/wrapper.sh#L64-L65

 

[rgarcia]

I checked the Chromium source (v145.0.7632.116) and WebAuthenticationConditionalUI no longer exists as a feature flag. It was present in earlier Chromium versions when conditional mediation was experimental, but it has since graduated and been removed. The only trace of it is in tools/metrics/histograms/enums.xml as a historical record.

In the current source, IsConditionalMediationAvailable in content/browser/webauth/authenticator_common_impl.cc unconditionally returns true:

// Desktop Chrome can always show GPM passkeys through conditional mediation.
std::move(callback).Run(true);

There's no feature flag gating this anymore, so --disable-features=WebAuthenticationConditionalUI will be silently ignored by Chrome.

There's also no enterprise policy to disable this (I checked the policy templates). Suppressing the passkey conditional UI on our Chromium build would require a source-level change — either making IsConditionalMediationAvailable return false, or gating it behind a new flag/policy.

Additionally, for headless pool browsers, the API sets CHROMIUM_FLAGS which overrides the wrapper.sh defaults, so the wrapper.sh change here wouldn't take effect in that path anyway. If we do find a working flag, it should go in browser_pool_activities.go in the API where the other --disable-features entries live.