What causes "Failed to start Passkey login" in QuantumNous/new-api?

Read the begin response body — res.message usually carries the real reason (e.g. no credentials registered).

QuantumNous/new-api · error · Error

Failed to start Passkey login

Error message

Failed to start Passkey login

What it means

Thrown in the sign-in form's Passkey handler when beginPasskeyLogin (the login-begin request) reports success:false without a server message key — the fallback 'Failed to start Passkey login' plus any server-provided message. It fires before any WebAuthn prompt, meaning the server refused or failed to issue credential request options.

Source

Thrown at web/src/features/auth/sign-in/components/user-auth-form.tsx:263

      return
    }

    if (!passkeySupported) {
      toast.error(t('Passkey is not supported on this device'))
      return
    }

    if (!navigator?.credentials) {
      toast.error(t('Passkey is not available in this browser'))
      return
    }

    setIsPasskeyLoading(true)
    try {
      const begin = await beginPasskeyLogin()
      if (!begin.success) {
        if (getServerErrorMessageKey(begin)) return
        throw new Error(begin.message || t('Failed to start Passkey login'))
      }

      const publicKey = prepareCredentialRequestOptions(
        begin.data?.options ?? begin.data
      )
      const flowToken = begin.data?.flow_token
      if (!flowToken) {
        throw new Error(t('Login flow expired. Please sign in again.'))
      }

      const credential = (await navigator.credentials.get({
        publicKey,
      })) as PublicKeyCredential | null

      if (!credential) {
        toast.info(t('Passkey login was cancelled'))
        return
      }

View on GitHub (pinned to e2c7aa7b10)

Solutions

Read the begin response body — res.message usually carries the real reason (e.g. no credentials registered).
Confirm the account actually has a registered passkey and that passkey auth is enabled in server settings.
Retry after signing in with password and registering a passkey.
If server-side misconfig, enable WebAuthn/passkey in backend options and verify the begin endpoint returns options + flow_token.

Defensive patterns

Strategy: try-catch

Validate before calling

if (!navigator?.credentials || !window.PublicKeyCredential) {
  toast.error(t('Passkey is not available in this browser')); return
}

Try / catch

try {
  const begin = await beginPasskeyLogin()
  if (!begin.success) {
    if (getServerErrorMessageKey(begin)) return // already surfaced globally
    throw new Error(begin.message || t('Failed to start Passkey login'))
  }
} catch (error) {
  if (getServerErrorMessageKey(error)) return
  toast.error(error instanceof Error ? error.message : t('Passkey login failed'))
}

Prevention

Hide the Passkey button when the account has no registered credentials or WebAuthn is unsupported
Verify server-side passkey enablement before exposing the option in the UI

When it happens

Trigger: POST to the passkey login-begin endpoint returns success:false (no options, no flow_token): user has no registered passkeys, WebAuthn disabled server-side, session/CSRF failure, or backend error.

Common situations: User clicked 'Sign in with Passkey' with no passkey registered for the account; server-side passkey feature flag off; expired CSRF/session on the begin endpoint; backend 500.

Related errors

AI-assisted analysis of QuantumNous/new-api@e2c7aa7b10 (2026-08-15). Data as JSON: /api/errors/67323ca495854fcd. Report an issue: GitHub.