Why are websites triggering passkey pop-ups when no passkey is available?

[s-h-a-d-o-w]

I've been getting pop-ups like this one:

But even though it says "your saved passkey", there's actually no passkey saved and so if I tap "sign in", all that happens if that KeepassDX opens and wants me to select some passkey, I guess.

I don't know what triggers this but KeepassDX has control over it and could not trigger it if there's no passkey available, it would be great.

[yudin-s]

This looks like KeePassDX reacting to a WebAuthn/passkey request from the website, not KeePassDX deciding on its own to show a prompt. The website calls the browser / Android Credential Manager with a public-key credential request, and Android then asks configured credential providers, including KeePassDX, whether they can provide something.

The current KeePassDX behavior explains the confusing part. In PasskeyProviderService.populatePasskeyData(), KeePassDX builds a search from the relying party ID and the request's allowCredentials list. If it finds matching entries, it offers those. If it finds no matching entry and allowCredentials is not empty, it errors because the site asked for specific credential IDs that KeePassDX does not have.

But if no matching passkey is found and allowCredentials is empty, KeePassDX still adds a generic pending intent for "passkey selection in opened database". That means a discoverable-passkey style request can still show KeePassDX even when there is no saved passkey for that site. After tapping it, you land in KeePassDX and have to select something, which matches what you described.

So I would classify this as a UX/filtering issue in KeePassDX's provider response: for an opened database with no matching passkey for the relying party, it probably should either return no PublicKeyCredentialEntry, or only show the generic picker if KeePassDX can reasonably create/use a relevant passkey for that request. Otherwise Android's generic text makes it look like a saved passkey exists when it does not.

A useful bug report would include:

Android version
KeePassDX version
Browser/app where the prompt appears
Whether the KeePassDX database is already unlocked
Whether any passkey entries exist at all, and whether any match that domain/relying party

If this explains the behavior, please mark it as the answer so the maintainer can focus on the provider filtering/UX part.

[s-h-a-d-o-w]

Android version: 16
KeePassDX version: 4.4.5
Browser/app where the prompt appears: Brave
Whether the KeePassDX database is already unlocked: No
Whether any passkey entries exist at all, and whether any match that domain/relying party: One passkey that doesn't match exists

[yudin-s]

Thanks, that data matches the code path pretty well.

With Android 16, KeePassDX 4.4.5, Brave, a locked database, and one unrelated passkey, the useful bug summary is probably:

KeePassDX is offered for a passkey request even when the database has no passkey matching the relying party.

The important detail is that the unrelated passkey should not be enough to show a useful passkey choice for the current site. If the request has an empty allowCredentials list, KeePassDX currently has fallback paths that can still present a generic locked-database / opened-database passkey selection entry. That explains why Android shows KeePassDX even though there is no matching passkey for the site.

For a focused issue, I would include exactly the matrix you posted plus the expected behavior: if no entry matches the relying party, KeePassDX should not advertise a usable passkey entry for that request, or it should make the generic unlock/select flow clearly distinguishable from "a matching passkey exists". That should give the maintainer a concrete provider-filtering case to evaluate.