[BUG] Windows: passkey/2FA step in the built-in browser hangs the entire app; it then hung on every launch until the profile was recreated

Environment

• Claude Desktop for Windows (MSIX-packaged): 1.26832.0.0 (package Claude_1.26832.0.0_x64__pzs8sxrjxfjjc)
• Windows 10 Pro 10.0.19045
• Claude Code CLI bundled at the time: 2.1.222

Summary

While already logged in to x.com in the built-in browser pane, the user started an "add account" flow to sign in with a second X account. At the passkey / 2FA step (the point where WebAuthn would invoke the native Windows Hello dialog), the entire app hung (not just the browser pane). The app had to be terminated, and it then hung again on every subsequent launch — effectively unbootable. Recovery was achieved by recreating the %APPDATA%\Claude profile.

Steps to reproduce (as experienced; not re-run since — reproducing kills the running session)

1. Open the built-in browser pane and log in to x.com (account A).
2. Start "Add account" on x.com and sign in as account B.
3. Proceed to the passkey / 2FA verification step.
4. App-wide hang. The app has to be terminated.
5. Relaunch the app → hangs again during/just after startup, every time.
6. Recovered after deleting/recreating the %APPDATA%\Claude profile.

Evidence (from Windows Event Log and app logs)

Windows Application event 1002 at 2026-08-08 02:23 JST (excerpt):

プログラム claude.exe バージョン 1.26832.0.0 は、Windows との対話を停止し、終了しました。
アプリケーション パス: C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\claude.exe
停止の種類: Quiesce

Matching WER event 1001: イベント名: MoAppHang, problem signature P1: Claude_1.26832.0.0_x64__pzs8sxrjxfjjc / P2: praid:Claude / P3: 1.26832.0.0 / P4: 6a550db4 / P5: 4185 / P6: 2097152 (no cab uploaded). Only one MoAppHang report was recorded for this episode; WER de-duplication likely suppressed reports for the subsequent identical hangs.

• No Crashpad dumps and no APPCRASH (Id 1000) events were produced — consistent with a hang, not a process crash.
• The pre-reset app logs were lost with the profile. The fresh main.log (created after the profile reset) shows 8 Starting app entries in a ~20-minute window (04:15–04:35 JST) — consistent with repeated launch attempts during recovery — followed by one more start at 07:06 JST, after which the app has been stable.

Hypothesis

The WebAuthn/passkey step invokes a native OS authentication dialog (Windows Hello). At that point the app's window stops pumping messages (matches the MoAppHang "Quiesce" stop type). The subsequent unbootable loop suggests session restore re-creates the pending auth window/state on every launch, reproducing the same hang until the profile (and thus the restored session) is wiped.

Workaround / mitigation

• Avoid new sign-ins / passkey / 2FA flows in the built-in browser entirely (use a normal external browser for authentication; keep the built-in browser for already-authenticated sessions).
• Untested idea: recovery without a full profile wipe might be possible by resetting only the browser/session stores under %APPDATA%\Claude (Partitions, Network, Session Storage, IndexedDB, Local Storage, WebStorage, blob_storage, DIPS*) while keeping claude-code, logs and config files — we have not needed to exercise this yet.

Related

• #77473 reports the built-in browser blocking passkey (WebAuthn) authentication on macOS. This Windows case looks like the same underlying gap, but escalates from "login blocked" to an app-wide hang plus a persistent hang-on-launch loop, which makes it considerably more severe.