fix(api): only classify a passkey as switchable when a code method exists

Merged
TO
3mo ago
+9-9

What

Follow-up to the review on the sign-in classifier (the earlier fixes merged in #3527). This closes the remaining nuance on the passkey finding.

Previously passkey meant "a passkey prompt with any other method available." But if that other method is a device approval / push / email-link (not a code), the take-over panel would still tell the user to "choose an authenticator/SMS/email code and enter it" — even though no code method exists.

Now the classifier is precise:

  • passkey — a passkey/security-key prompt AND a code-based method (authenticator app, SMS, or email code) can be chosen instead.
  • passkey_only — a passkey/security key with no usable alternative.
  • other — anything else, including a passkey prompt whose only alternative is a device approval / push / email link (so it routes to the generic "finish sign-in yourself" panel, not the code panel).

Scope

Prompt wording only in browser-login-classifier.ts (classifyTwoFactorMethod). No contract/type change.

Note

This is LLM-prompt hardening — behavior isn't 100% guaranteed — but it removes a misleading-guidance edge case, and take-over stays interactive so it degrades gracefully.

Tests

12 classifier tests green (they assert the return-value contract; mocked extract), typecheck clean.

Summary by cubic

Fix sign-in 2FA classification so "passkey" is only returned when a code-based alternative (authenticator app, SMS, or email code) is available. Passkey prompts that only offer device approval/push/email link are now "other," preventing code-entry guidance when no code exists.