Desktop app: daily forced re-login (session_stale_relogin) + scheduled-task run freezes mid tool call and silently skips all subsequent runs

Seeing the same thing on macOS, and I have a corroborating detail that may help narrow the root cause: the cookie jar comes back empty on every launch, not just the sessionKey.

Environment

• Claude Desktop 2.2553.1 (same as OP), embedded Claude Code 2.1.275
• macOS 26.5.2 (25F84), arm64
• App installed in /Applications, no quarantine attribute

Onset matches: 2026-09-18

[account] Login-state transition (loggedOut: true → false) appears at every launch starting Sept 18, and never before it:

2026-09-18 17:16:10 [info] [account] Login-state transition (loggedOut: true → false, ...)
2026-09-18 23:44:35 [info] [account] Login-state transition (loggedOut: true → false, ...)
2026-09-20 12:35:44 [info] [account] Login-state transition (loggedOut: true → false, ...)
2026-09-21 10:19:08 [info] [account] Login-state transition (loggedOut: true → false, ...)
2026-09-22 09:25:28 [info] [account] Login-state transition (loggedOut: true → false, ...)

Each boot is preceded by:

[hybrid] boot: no hold { reason: 'no session' }
claudeURLHandler: login loadURL superseded (teardown race)

Launches on Sept 17 and earlier came up already signed in, with no such transition.

The whole cookie jar is empty at boot, not just sessionKey

Querying ~/Library/Application Support/Claude/Cookies after a launch, every row was created during that launch — including cookies with multi-year expiries that should long predate it:

| cookie | expires | created |
|---|---|---|
| sessionKey | 2026-10-20 (28d out) | this launch, 09:25 |
| anthropic-device-id | 2027-07-19 | this launch, 09:24 |
| _fbp | 2027-10-27 | this launch, 09:24 |

19 rows total, oldest creation_utc = app start time. The Cookies file itself dates from my install in June, so it is not being deleted or recreated — it comes back empty. And sessionKey carries a 28-day expiry, so this is not a short-TTL policy.

Worth noting this is specific to cookies: Local Storage/leveldb does persist across days in the same profile, so the profile is not being wiped wholesale.

The preceding quit was clean

Not a dirty-shutdown / unflushed-jar problem — the quit handler that flushes storage ran and completed:

[quit-cleanup] previous quit: {
  completed: true,
  cleanup_ms: 255,
  handler_count: 34,
  slowest_handler: 'flush-web-storage',
  slowest_ms: 252,
  timed_out: false,
  pending_handlers: [ [length]: 0 ],
  watchdog_fired: false,
  for_update: false,
  quit_app_version: '2.2553.1'
}

session_stale_relogin is the same error class, and predates the daily loop

I have it in my logs going back to late August, when it showed up as scope-expansion failures rather than full re-login:

2026-08-28 19:33:49 [info] oauth authorize rejected with session_stale_relogin; sessionKey is valid but too old for the requested scope expansion
2026-08-28 19:33:49 [info] [oauth-v2] fresh exchange failed for orgId=<redacted> (session_stale_relogin)
2026-08-28 19:33:49 [warn] Cannot get base query config: oauth failed (session_stale_relogin): Session is not fresh enough to grant elevated access. Sign in again to continue.

So "sessionKey is valid but too old" existed well before Sept 18; what changed on Sept 18 looks like the handling of it.

Ruled out locally (in case others are chasing these)

• Single Claude Safe Storage keychain item, created at install, never rotated or duplicated — safeStorage decryption is not failing
• Login keychain is no-timeout, unlocked, and the default keychain
• No Gatekeeper translocation, no quarantine xattr
• No cleaner/privacy utilities or launch agents touching the profile
• No auth/session/persistence keys in config.json — only oauth:tokenCache / oauth:tokenCacheV2. There is no client-side setting to opt out of this.

The open question

I can't yet tell whether the app (a) fails to persist cookies at quit, or (b) persists them fine and clears the jar at startup after the server rejects the stale session. My quit-cleanup block suggests the flush happens, which points at (b) — but a snapshot of Cookies taken between quit and next launch would settle it. Happy to capture that if it's useful.

Same on macOS 14.8.4, Claude Desktop 2.16120.0, Google SSO. Forced re-login on launch after an overnight quit since ~Sep 27 (Sep 27, 28, 29, 30, Oct 1). main.log at each launch:

[startup-sign-in] state: {
  sign_in_cookie_present: true,
  signed_in_at_last_exit: true,
  previous_quit_clean: true
}

The sessionKey cookie persists locally (28-day expiry, decrypts fine, clean quits), and the server rejects it on the next launch. Earlier logs show 403 session_stale_relogin ("sessionKey is valid but too old for the requested scope expansion"). Quick restarts (minutes) mostly do not trigger it.

I am a paying subscriber, and the Claude Desktop app on Linux has become unusable for real work. Since late September I have been forced to sign in again over and over, at worst every 2–3 hours. Every forced logout breaks running sessions and interrupts my work. That is not an inconvenience. It is a broken product that I pay for every month.

This is not a configuration problem on my side. My logs show the server rejecting a valid session:

oauth failed: authorize returned 403 <json error=permission_error code=session_stale_relogin>
oauth authorize rejected with session_stale_relogin; sessionKey is valid but too old for the requested scope expansion
[oauth-v2] fresh exchange failed (session_stale_relogin)
[remote-tools-device] oauth token unavailable: session_stale_relogin

The app also registers with the server only as a keyless device, from the very first launch:

[device-registry] enclave key unavailable — refusing to resolve row-PK
[remote-tools-device] connect frame sent: device_id keyless (row_pk_directory)

Logs confirm forced re-logins on Sep 27, Sep 30, Oct 4, Oct 5, Oct 10, Oct 11 and Oct 13. The GNOME keyring is running and cookie encryption works. The system clock is NTP-synced. Nothing on my machine explains this.

Environment: claude-desktop 2.9939.4 (apt), Claude Code 2.1.284, Linux 7.2.8, GNOME.

This is a known issue, and it is being ignored:

• anthropics/claude-code#95963: open since Sep 22, no assignee, reports escalating from 14 to 85 per day
• aaddrick/claude-desktop-debian#913: same log lines, same version; the root cause was traced to Linux having no hardware-bound
• device key (linux-not-yet-supported), so every Linux install is keyless and gets its sessions killed early. The maintainer confirmed this is on your side.
• anthropics/claude-code#96235: same symptom on Linux, also unassigned

What I expect:

• Assign an engineer to anthropics/claude-code#95963 now and give a public status update.
• Stop invalidating valid sessions on keyless (Linux) devices. Refresh them silently, as you did before Sep 18.
• Give a timeline for the fix.
• Until it is fixed, consider compensating affected paying customers for the lost productivity.
• You advertise Claude Desktop for Linux. Then support it properly. I expect a substantive answer, not a template response.