Skip to content

[FEATURE] Passkey (WebAuthn) sign-in for Claude accounts, across every surface #84862

Description

@mccarthysean

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

Signing in to a Claude account currently offers two paths: "Continue with Google", or an emailed magic link / one-time code. If Google sign-in isn't an option for you, the magic link is the only path — and it's slow and failure-prone:

Those two facts interact badly. Five of the ten minutes are typically gone before the email lands, and nobody sits and watches an inbox for five minutes — so I step away, come back, and the link has expired. Then I request another one and try to time it better. The usable window is far shorter than the stated 10 minutes.

The cost is then multiplied by the number of surfaces. I sign in on five: the Claude mobile app, Claude Code, the web app, Claude for Excel, and Claude for Chrome. Each holds its own credential and expires on its own schedule, so this isn't a one-time setup cost — it's a recurring interruption that lands several times across my clients.

Passkeys are the standard answer to exactly this: instant, local, phishing-resistant, and already supported by the OS keychain or password manager on every device I use.

Proposed Solution

Make a passkey (WebAuthn/FIDO2) a first-class sign-in method for Claude accounts, on equal footing with "Continue with Google" and email:

  1. Enrollment. In account settings, an "Add a passkey" flow supporting both platform authenticators (Windows Hello, Touch ID, Android) and roaming ones (hardware security keys). Multiple credentials enrolled concurrently, each named, listable, and individually revocable.

  2. Sign-in. On the login screen, alongside "Continue with Google" and "Continue with email", a "Sign in with a passkey" option that triggers the standard WebAuthn prompt — no email round-trip, no expiry window.

  3. Every surface. Offer it anywhere a magic link works today: claude.ai, the desktop app, the mobile apps, and the browser-based OAuth flow. Because Claude Code, the VS Code extension, Claude for Excel, and Claude for Chrome all authorize through a browser session, adding passkey sign-in to that flow covers all of them in one change.

  4. Additive, not a replacement. Magic link and Google sign-in stay exactly as they are.

One note on what already exists: something passkey-shaped is shipping under the name "Trusted Devices" — Claude Desktop prompts to set one up after login, and it backs Remote Control device auth. But as far as I can tell it isn't a sign-in method; it's a device-trust step layered on top of a login I still have to complete by email. It's also undocumented, single-credential only (#82095), crashes during setup on macOS (#81550), fails to enroll on Linux (#83122), and conflicts with the VS Code "Prefer Agent Host" setting (#84582). This request is for the sign-in half.

Alternative Solutions

Things I've tried or considered. None of them closes the gap:

  • Continue with Google. The best current workaround — it skips email entirely. But it requires tying the account to a Google identity, which isn't available or acceptable to everyone, and it puts another party in the authentication path.
  • Sign in once in a browser and let the other clients ride that session. This already works and genuinely helps: /login in Claude Code, the VS Code extension, Claude for Excel, and Claude for Chrome all authorize off an existing claude.ai browser session, so each is a one-click approve. But it only defers the problem — when the browser session expires I'm back to waiting on an email, and every downstream client needs re-authorizing.
  • claude setup-token. A one-year CLAUDE_CODE_OAUTH_TOKEN covers the CLI, but it's scoped to model requests only (no Remote Control, no claude.ai connectors) and does nothing for mobile, web, Excel, or Chrome.
  • Just waiting at my desk for the email. Works. Isn't a workflow.
  • Fixing delivery speed or extending the 10-minute expiry. Both would reduce the pain — and Claude.ai sign-in (magic link) emails delayed 2-5 minutes since mid-July 2026 #82049 should be fixed regardless — but neither removes the round-trip.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

A normal Monday morning:

  1. I open Claude Code to start work. It reports my login has expired.
  2. /login opens a browser tab. My claude.ai browser session has expired too, so I land on the login screen.
  3. I enter my email and click Continue. Claude sends a magic link.
  4. Nothing arrives within 30 seconds, so I switch back to what I was doing.
  5. Six minutes later I remember, open my inbox, click the link — expired. Back to step 3.
  6. Second attempt. This time I wait at my inbox until it lands. Claude Code is authorized.
  7. Later that morning: Claude for Excel prompts separately. Claude for Chrome prompts separately. My phone prompts separately.

With passkey sign-in, steps 3–6 collapse into: click "Sign in with a passkey", approve with Windows Hello, done in about two seconds. Step 7 largely collapses too, since those surfaces authorize off the browser session established in step 2.

Additional Context

Related issues:

Prior art: GitHub, Google, Microsoft, Apple, Cloudflare, and 1Password all offer passkeys as a primary sign-in method with multiple enrolled credentials. GitHub's own implementation is a good reference — passkeys sit alongside the other methods, you can enroll several, name them, and revoke them individually.

Worth noting that the Help Center article on signing in still lists only Google and email, with no mention of passkeys or Trusted Devices, so even the partial functionality that exists today isn't discoverable: https://support.claude.com/en/articles/13189465-log-in-to-your-claude-account

My environment: Windows 11, using Claude Code, Claude Desktop, Claude for Excel, Claude for Chrome, and the Claude mobile app.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions