Codex App in-app browser does not invoke passkey/WebAuthn platform authenticator
Description
The Codex App in-app browser shows passkey-capable login UIs on sites such as Notion and Google, but pressing the passkey option does not open the macOS/iCloud Keychain passkey sheet.
This appears to be more specific than generic OAuth popup/login support: the page-level WebAuthn APIs are present, but the embedded browser reports that no platform authenticator is available.
Related broader issue: #19276.
Reproduction
- Open the Codex App in-app browser (
@Browser). - Navigate to a page with a passkey login option, for example Notion or Google login.
- Click the passkey option.
Observed: the button/focus state changes, but no native passkey prompt appears.
I also reproduced with a minimal local WebAuthn diagnostic page on http://localhost:
await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
Result in Codex in-app browser:
{
"isSecureContext": true,
"credentialsObject": true,
"credentialsCreate": "function",
"credentialsGet": "function",
"publicKeyCredential": "function",
"platformAuthenticatorFn": "function",
"conditionalMediationFn": "function",
"platformAuthenticatorAvailable": false,
"conditionalMediationAvailable": true
}
Calling navigator.credentials.create() or navigator.credentials.get() from an actual click does not open the native passkey sheet; the call hangs until aborted/timed out.
Comparison
The same diagnostic page opened via the Codex Chrome extension in regular Chrome reports:
{
"platformAuthenticatorAvailable": true,
"conditionalMediationAvailable": true
}
So the machine and Chrome profile can use platform passkeys; the limitation appears isolated to the Codex in-app browser.
CDP workaround attempt
I also tried the standard WebAuthn virtual authenticator workaround via CDP in the in-app browser:
WebAuthn.enable
WebAuthn.addVirtualAuthenticator
Both were rejected with:
This method is not supported through raw CDP.
That means even test-only WebAuthn emulation is currently unavailable in the in-app browser.
Expected behavior
One of these would be useful:
- Support macOS/platform passkeys in the Codex in-app browser.
- Provide a supported external-browser handoff so auth can complete in Chrome/Safari and return to the in-app browser where possible.
- Document passkeys/WebAuthn as unsupported and surface a clear in-app error/fallback instead of silently failing.
- Allow CDP
WebAuthn.*virtual authenticator commands for local/test flows.
Environment
- Codex App: 26.623.101652, build 4674
- macOS: 26.5 (25F71)
- Chrome comparison: Google Chrome 149.0.7827.201
- In-app browser user agent observed:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36
Workaround
For real user passkeys today, use the Codex Chrome extension (@Chrome) rather than the in-app browser (@Browser). That works because it uses the user's actual Chrome profile and platform passkey support.
For local/test passkey flows, there does not appear to be an in-app browser workaround because CDP WebAuthn.* is blocked.
2 Comments
Adding a macOS UX report / feature request from a Codex Desktop user:
When a site offers a passkey in Codex’s in-app browser, the available flow falls back to a QR code that must be scanned with an iPhone. The user cannot select a locally available passkey from iCloud Keychain and complete it with the normal macOS Touch ID credential picker, as they can in Google Chrome.
Requested outcome: support native macOS platform passkeys in the in-app browser, so standard WebAuthn prompts can use a local iCloud Keychain (or compatible credential-manager) passkey and display the usual Touch ID confirmation. The QR/cross-device flow should remain a fallback, rather than the only option.
One possible implementation lead — not a prescription — is Apple’s
ASAuthorizationWebBrowserPublicKeyCredentialManager, includingrequestAuthorizationForPublicKeyCredentials(...). Apple documents it as the browser-side API for requesting a person’s permission to use platform passkeys. The right implementation may be different, but it should produce the same user-visible behavior.Expected behavior: if an eligible local passkey exists, Codex presents the standard macOS passkey chooser / Touch ID flow without requiring a phone or QR-code handoff.
Relevant Apple docs: https://developer.apple.com/documentation/authenticationservices/passkey-use-in-web-browsers and https://developer.apple.com/documentation/authenticationservices/asauthorizationwebbrowserpublickeycredentialmanager/requestauthorizationforpublickeycredentials%28_%3A%29
Matter of fact, I want codex to be my default browser. the Aside browser has a interesting password management implementation and they do the passkey thing correctly, maybe it can serve as inspiration. but yeah, then they could "rename" The Atlas app Instead of shutting it down like they did with the old Mac OS app when they merged it with the Codex desktop and retain all of those users. all into one superior desktop app like they've been clearly gunning for. Full browser, IDE, the whole shebang.