[BUG] Windows desktop app logs user out on cold start when account_profile bootstrap returns undefined — session cookie is still valid; breaks Remote Control device pairing

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 16, 2026

Environment

  • Claude Desktop (Microsoft Store / MSIX), observed on 1.18286.0.0 through 1.21459.0.0, and reproduced on 1.21459.3.0 (2026-07-16 14:37, hours after auto-updating to it — the update does not fix this)
  • Windows 11 Home, build 26200.8875
  • Package family: Claude_pzs8sxrjxfjjc

Summary

On some cold starts of the desktop app, the claude.ai web view loads, briefly reports the account as active and logged in, then the account_profile query resolves with undefined data and the web app responds by navigating to https://claude.ai/logout — destroying a session that was still valid moments earlier. The user is forced to re-authenticate. This has recurred at least 6 times over 6 weeks (2026-06-07, 07-03, 07-05, 07-07, 07-16 08:28, 07-16 14:37 — the last on 1.21459.3.0) and, because it usually fires on the first launch after a reboot, it presents to the user as "Windows keeps losing my credentials."

Evidence (from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs)

Timeline 2026-07-16 (first launch after a clean Windows Update reboot the prior evening; Wi-Fi confirmed connected at 08:25:27, ~2.5 min before app start):

main.log
08:28:00 [info] Starting app {
08:28:04 [info] Loaded https://claude.ai (web commit 71ff17293b..., desktop commit f7518fa0...)
08:28:04 [info] claude.ai account details provided
08:28:04 [info] claude.ai account active and logged in        <-- session cookie WAS valid
08:28:04 [warn] No org ID available, cannot update cached allowlist status
08:28:04 [info] [account] User logged out during IPC wait, stopping early
08:28:05 [warn] Blocked permission check { ... topFrameUrl: 'https://claude.ai/logout' }   <-- web view navigated to /logout
08:28:06 ...    topFrameUrl: 'https://claude.ai/login?from=logout'
08:29:05 [info] [account] Login-state transition (loggedOut: true -> false, uuid unchanged), preserving oauth cache (same-user re-login)
claude.ai-web.log
08:28:04 [error] [REACT_QUERY_CLIENT] QueryClient error: {"message":"[\"account_profile\"] data is undefined", ...
    at Object.onSuccess (https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/vendor-query-w8ME5CaM.js:...)"}

The ["account_profile"] data is undefined error appears in the web log on exactly the dates of every logout incident: 2026-06-07, 07-03 (09:10), 07-05 (16:24), 07-07 (09:38), 07-16 (08:28), 07-16 (14:37). Zero occurrences during a continuous 2026-07-08 → 07-15 uptime week.

Second same-day recurrence on 1.21459.3.0 (2026-07-16, ordinary user-initiated app restart — no reboot)

main.log
14:37:33 [info] claude.ai account active and logged in         <-- session valid
14:37:34 [info] [account] User logged out during IPC wait, stopping early
14:37:34–35     repeated "[account] User is logged out, skipping account ID wait"
                topFrameUrl: 'https://claude.ai/logout' (x2), then 'https://claude.ai/login?from=logout'
14:38:12 [info] [account] Login-state transition (loggedOut: true → false, uuid unchanged), preserving oauth cache (same-user re-login)
claude.ai-web.log
14:37:34–35 [error] [REACT_QUERY_CLIENT] QueryClient error: {"message":"[\"account_profile\"] data is undefined", ...}  (x3)

This instance occurred on 1.21459.3.0, hours after auto-updating to it — confirming the bug survives the update.

Downstream impact: breaks Remote Control device pairing

Beyond the forced re-login, the race breaks Claude Code Remote Control on the machine in two observable ways:

  1. CLI sessions repeatedly failed the Remote Control handshake until the circuit breaker tripped ("Remote Control failed · disabled after repeated failures · restart to retry"), then demanded re-auth ("Remote Control failed · /login") — the bridge endpoint (wss://bridge.claudeusercontent.com) was verified reachable (DNS/TCP/TLS all clean, HTTP 426 from the endpoint), so the failures were auth-layer, consistent with the session invalidations caused by the spurious /logout navigations.
  2. During the 14:37 incident, main.log captured the app being bounced off a Remote Control session page to a login URL carrying the failure reason (from=logout ties it to the race):
topFrameUrl: 'https://claude.ai/login?returnTo=%2Fepitaxy%2Fsession_01Cdnroaerd...%3Freason%3Delevated_auth%26auth_kind%3Ddevice_key_missing%26org_uuid%3D476dd1e7-...&reauth=1&from=logout'

auth_kind=device_key_missing — each spurious logout leaves the desktop without a registered device key, so the mobile app's "add a device" pairing flow cannot complete against this machine, and elevated-auth session pages bounce to login.

Key data points ruling out local/OS causes

  1. Not file corruption / not Windows: Network\Cookies, Local State (os_crypt key), Local Storage, and ~/.claude/.credentials.json all survived intact across every incident (creation timestamps unchanged since 2026-06-07). The 2026-07-15 reboot was a clean Windows Update servicing restart — no Event 41/6008.
  2. Not a kill-before-flush race: the 2026-07-05 16:24 incident followed a graceful app quit (willQuit: handler fired ... quitting), same app version before/after, no OS reboot — and the very next start hit the logout 3 seconds in.
  3. Not the network: on 2026-07-16, Wi-Fi connected at 08:25:27; app started 08:28:00; page and JS assets loaded from the network; no ERR_*/offline errors anywhere in the logs.
  4. Session was valid: the same startup logged claude.ai account active and logged in one line before the logout, and the re-login one minute later resolved to the identical account uuid.
  5. Intermittent per cold start: the very next relaunch the same morning (09:10, post-auto-update) started logged-out transiently and recovered to logged-in by itself in 22 s. Several other restarts (2026-07-10, 07-11, 07-14, 07-15) had no incident.

Expected behavior

A transient empty/failed account_profile bootstrap on a fresh cold start should be retried (or surface an error state), not treated as an authoritative "user is logged out" signal that navigates to /logout and invalidates the local session.

Actual behavior

The web app hard-logs-out, destroying a valid session; the user must re-authenticate. Recurs every few reboots, and each occurrence de-registers the machine's device key, breaking Remote Control pairing until a fresh full sign-in.

View original on GitHub ↗