Codex in-app browser should support Apple "Sign in with Passkey" WebAuthn prompts

Summary

The Codex Desktop in-app browser appears not to support the Apple Account / App Store Connect Sign in with Passkey WebAuthn flow. This is not the separate Sign in with Apple OAuth-style identity button; it is Apple’s passkey button on the Apple Account login screen.

This makes authenticated browser tasks much more cumbersome because the user has to type a password even when the site supports platform passkeys in regular browsers.

Concrete case: App Store Connect sign-in. The same Apple Account/App Store Connect login can use the Sign in with Passkey button in normal browsers, but inside the Codex in-app browser the passkey flow does not work, so the user has to fall back to password entry.

Specific Apple flow / naming

The App Store Connect login page shown inside the Codex in-app browser exposes this exact control:

button "Sign in with Passkey"
paragraph "Requires a device with iOS 17 or later."

A screenshot captured from the Codex in-app browser on 2026-06-21 shows the App Store Connect login card with:

• the Email or Phone Number input
• a disabled Continue button
• a black Sign in with Passkey button
• helper text: Requires a device with iOS 17 or later.

!App Store Connect login showing the Apple Sign in with Passkey button

Official Apple docs use the same naming for this web login flow:

• Apple Support says iCloud.com users can choose Sign in with Passkey and use a nearby iPhone/iPad QR-code flow when iCloud Keychain and supported OS versions are available: https://support.apple.com/guide/icloud/sign-in-and-use-icloudcom-mm281e3e7d/icloud
• Apple’s passkeys overview describes Apple passkeys as Face ID / Touch ID-backed credentials that sync through iCloud Keychain and can use an iPhone to sign in on non-Apple devices: https://developer.apple.com/passkeys/
• Apple’s passkey security doc describes passkeys as WebAuthentication/WebAuthn credentials based on public-key cryptography, with Touch ID/Face ID authorizing passkey use and iCloud Keychain synchronization: https://support.apple.com/en-us/102195

Environment

• Codex CLI/Desktop bundled runtime observed: codex-cli 0.142.0-alpha.6
• Browser plugin release observed: 26.616.51431
• macOS: 26.3.1 (25D2128), arm64
• Site where this was observed: App Store Connect login (https://appstoreconnect.apple.com/login)

Reproduction

1. Open Codex Desktop's in-app browser.
2. Navigate to App Store Connect login.
3. Use an Apple Account that has passkey sign-in available.
4. Click the Apple Account Sign in with Passkey button.
5. Attempt to complete the WebAuthn/passkey prompt via the host OS, iCloud Keychain, Touch ID, or nearby iPhone/iPad flow.

Actual behavior

The in-app browser does not successfully complete the Apple Account Sign in with Passkey WebAuthn flow. The user has to type the account password instead.

Expected behavior

Codex's in-app browser should support standard WebAuthn/passkey flows where the host OS/browser can present the platform authenticator prompt, such as macOS/iCloud Keychain/Touch ID passkeys or Apple’s nearby iPhone/iPad passkey flow for Apple Account sign-in.

At minimum, if passkey/WebAuthn is not supported in the in-app browser, Codex should make that limitation clear or provide a secure supported handoff path that does not require agents to switch to unrelated foreground browser automation.

Why this matters

For authenticated browser tasks, Codex's in-app browser is the right background-safe surface. If Apple Account passkeys fail there, users are forced into repeated password entry or into external browser workarounds. That is both slower and worse for security/UX, especially for App Store Connect workflows where passkey sign-in works elsewhere.

Related context

This came up immediately after the in-app browser MCP issue was fixed in #29219. The browser automation path is now usable again, but App Store Connect still requires manual password sign-in because Apple Account Sign in with Passkey does not work inside the in-app browser.