[BUG] Built-in browser does not support passkey (WebAuthn) authentication on macOS — blocks GitHub login

Status Open

Reported on v2.1.142

Maintainer reply None cached

Activity 3 comments · opened Jul 14, 2026

What happened

The Claude Code built-in browser on macOS does not support passkey (WebAuthn / platform authenticator / Touch ID) authentication. When a site requires a passkey to log in — in my case GitHub — the passkey prompt does not work in the built-in browser, leaving me unable to authenticate.

Concrete impact: I could not log into GitHub in the built-in browser to review a pull request. There is no fallback to the platform authenticator, so passkey-only or passkey-preferred logins are a dead end.

Environment

Claude Code 2.1.142
macOS (Darwin 25.5.0)
Built-in / embedded browser

Expected

The built-in browser should support passkey / WebAuthn (platform authenticator via Touch ID), or fall back to the system default browser for auth flows that require a passkey, so logins to sites like GitHub complete.

Related (same class of built-in-browser auth limitations)

#76548 — preview pane cannot do HTTP Basic Auth (native dialog unsupported)
#76965 — embedded browser pane shows blank content on macOS
#64630 — macOS does not use the default browser for logging in

View original on GitHub ↗

3 Comments

andyleeboo · 1 month ago

Still reproduces on Claude Code 2.x (browser pane UA Claude/1.37937.1 Chrome/148.0.777, macOS Darwin 25.6.0).

Evaluated in the browser pane on an HTTPS origin with passkey sign-in:

window.PublicKeyCredential                                          // present
window.isSecureContext                                              // true
await PublicKeyCredential.isConditionalMediationAvailable()         // true
await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
// => false

So the WebAuthn interface is exposed but no platform authenticator is available. Sites that feature-detect on window.PublicKeyCredential render their passkey button, and clicking it hangs on "Preparing..." with no error and no fallback.

Case today: admin sign-in for a self-hosted EmDash CMS on my own domain. Same flow completed normally in Safari.

sulton-max · 12 days ago

same here, for most of the stuff built-in browser is not usable

presfunkmann · 4 days ago

Still reproduces on Claude/2.31226.1 (Chrome/152.0.7977.130), macOS. It's changed since the Aug diagnostic: isUserVerifyingPlatformAuthenticatorAvailable() now returns true, and getClientCapabilities() reports passkeyPlatformAuthenticator: true and hybridTransport: true. But navigator.credentials.get() on webauthn.io (discoverable, empty allowCredentials, document focused, transient user activation present) rejects with NotAllowedError in ~19ms, and no system passkey sheet or QR code ever appears. So the pane advertises passkey support it can't deliver, and sites show passkey buttons that always fail.