Detailed Analysis
A Reddit user has documented an apparent staged rollout of passkey enrollment within the Claude Desktop app on macOS, a feature that appears nowhere in Anthropic's official documentation, release notes, or claude.ai settings pages. The user, prompted to re-authenticate, was subsequently offered the option to create a passkey to bypass future email-link verification. Critically, the enrollment flow routes exclusively through Apple Passwords (iCloud Keychain), with no apparent mechanism to select a third-party password manager instead. The same offer did not surface in a fresh browser sign-in attempt, suggesting the feature—if it is indeed live—is currently confined to the desktop application rather than the web client.
The technical constraint driving this behavior appears rooted in how Claude Desktop implements authentication. According to details the user surfaced from GitHub issues, the app uses an in-app WebKit sheet (ASWebAuthenticationSession) to handle sign-in, which structurally prevents browser extensions from intercepting the WebAuthn request. Since Apple does not offer a system-level passkey provider selection mechanism on macOS comparable to what exists on iOS, any passkey generated through this in-app flow defaults to Apple's own credential store. This is a meaningful usability gap for the substantial population of users who rely on third-party password managers like 1Password, Bitwarden, or Dashlane as their primary credential vaults. Those users are effectively locked out of a clean passkey enrollment path unless they are willing to fragment their credential management across two systems.
The stakes here extend beyond simple inconvenience. One linked GitHub issue reports that accepting the passkey prompt caused the app to crash entirely, while another describes a Windows user who successfully enrolled a hardware FIDO2 security key, only to discover that Claude's implementation supports just one authenticator per account—enrolling a second key requires deleting the first and re-registering, and this can only happen at sign-in time rather than proactively through settings. This suggests the feature is genuinely half-built or still being iterated on internally, rather than a polished, ready-to-announce capability. The existence of a long-standing but perpetually empty "Trusted devices" section in account settings, which only now began populating for this user, further supports the theory that Anthropic has had passkey infrastructure partially in place for some time and is now testing activation triggers selectively.
This episode is illustrative of a broader pattern across the AI industry, where authentication and security features are often rolled out silently or via A/B testing frameworks well ahead of public documentation, presumably to gather engagement data or catch edge-case bugs before a full announcement. Passkeys themselves represent an industry-wide push away from password-and-email-link authentication toward FIDO2/WebAuthn standards, and major platforms including Google, Microsoft, and Apple have been aggressively promoting adoption. However, this case highlights a persistent friction point in that transition: passkey ecosystems remain fragmented, and platform-level defaults (like Apple Passwords) can conflict with users' established credential management habits, especially in native desktop apps where browser-extension-based password managers have no hook into the authentication flow. For a company like Anthropic, which serves a technically sophisticated user base likely to have strong preferences about credential storage, shipping a passkey feature without a settings-based enrollment path or manager choice risks user distrust, even if the underlying security improvement is sound. The lack of transparency around the rollout—no changelog entry, no support article—also underscores a recurring tension between rapid iterative shipping and the kind of clear communication power users expect from security-adjacent features.
Read original article →