Passkeys, and re-authentication on approvals

Passkeys

Account → Passkeys → Add passkey registers one with your fingerprint, face, or security key. The login screen then offers Sign in with a passkey, which signs you in without the trip through GitHub.

A passkey mints an ordinary session. It is not a second factor, and ordinary work never asks for it again.

Naming

A new passkey is named after the authenticator holding it — iCloud Keychain, Windows Hello, YubiKey 5 Series, 1Password — read from the model the authenticator reports about itself. Authenticators that withhold it fall back to the browser and platform you registered from, Chrome on macOS.

Click a name to change it. The list also marks whether a passkey is Synced to a provider keychain or bound to This device, and when it was last used.

Approving a CLI login or a connector

Approving myna login, or an agent on the connector consent screen, now asks you to confirm it is you. A passkey answers that in place; otherwise you go through GitHub and land back where you were.

Both hand out a credential that keeps working after the session that approved it is gone — signing out does not take back a token already in a terminal, or a grant an agent already holds. The confirmation lasts five minutes, so approving a CLI login and a connector in one sitting only asks once, and signing in counts as one. Declining is never gated.

Clients driving either flow receive REAUTHENTICATION_REQUIRED naming the methods that would satisfy it. Servers advertise auth.passkeys and auth.reauth.

Recovery

GitHub stays linked on every account and remains a valid way to sign in, so a lost passkey is not a lockout: sign in with GitHub and register another. There are no recovery codes.

Removing a passkey is refused only when it is the account's last remaining way to sign in.

An account is reachable through GitHub either way, so it is only as secure as the GitHub account behind it. Keep two-factor authentication switched on there.