[BUG] Linux Desktop: session_stale_relogin (elevated_auth) forces ~daily re-login; sign-in demanded twice during Cowork folder-access grants

Confirming this on a different distro and with a different trigger. Same from=logout server-side redirects, plus a client-side error and a second auth_kind value that aren't in the original report.

Environment

| | |
|---|---|
| OS | Linux Mint 22.3 (Ubuntu 24.04 base), Cinnamon 6.6.9, X11 |
| App | claude-desktop 1.37937.3 (official apt build) |
| Account | Personal Max, no SSO |
| Devices | Same account signed in on several devices; Chat and Cowork used elsewhere too |

Trigger differs from the original report

The app does not need to stay running >24h. Reproduction here:

1. Sign in to Claude Desktop. Use the app normally, including at least one Cowork task (asking Claude to generate files from within Chat).
2. Suspend the machine, leave it idle overnight (~8h).
3. Wake the machine, open Claude Desktop.
4. Browse conversations and projects — this works normally.
5. Send any prompt.

Step 5 is where it fails. The failure fires on the first prompt sent, not at app launch. It affects any conversation, including a brand-new one outside any project with a trivial "ok" prompt. Model-independent (reproduced on Haiku and Fable).

Re-authenticating clears it immediately, until the next long idle period.

Client-side error (not in the original report)

~/.config/Claude/logs/claude.ai-web.log logs exactly one new line at the moment of failure:

[error] Uncaught (in promise) CcrHttpError: startRemoteCoworkSession: 403

The user-facing dialog reads: "Sign in to continue — Your session has expired. Sign in again to verify your identity."

That wording is misleading and costly. It sends users down an authentication-debugging path — keyring, OAuth, token storage — that has nothing to do with the actual failure. A 403 is not an expired credential. Worth fixing the error mapping independently of the session bug itself.

Second auth_kind value: untrusted_device

main.log shows two distinct variants (UUIDs redacted):

topFrameUrl: 'https://claude.ai/login?returnTo=%2Fcowork%2Fproject%2F<redacted>%3Freason%3Delevated_auth%26auth_kind%3Dsession_stale_relogin%26org_uuid%3D<redacted>&reauth=1&from=logout'

topFrameUrl: 'https://claude.ai/login?returnTo=%2Fcowork%2Fproject%2F<redacted>%3Freason%3Duntrusted_device%26auth_kind%3Duntrusted_device%26org_uuid%3D<redacted>&reauth=1&from=logout'

session_stale_relogin matches the original report. untrusted_device appears to be new here — and unexpected on a personal Max account with no SSO and no org device policy.

In both cases returnTo targets a Cowork project (/cowork/project/<id>), with a
different project id in each of the two lines — note this differs from the original
report's /cowork/<session_id> path. Consistent with the startRemoteCoworkSession
failure above.

Unexplained: one conversation stayed functional

While every other conversation failed, one already-open conversation kept working normally — prompts sent and answered — for the entire duration. It survived two full app restarts (killall + relaunch) and an app update, and still worked.

I have no explanation for this and can't reconcile it with a purely session-level invalidation. Flagging it in case it narrows down which state is actually being invalidated.

Ruled out locally

In addition to the original report's list:

• Autologin disabled — the login keyring is unlocked normally via PAM
• Chromium Safe Storage present in the persistent login keyring (checked via secret-tool and seahorse)
• ~/.config/Claude/ — Cookies, Preferences, Network Persistent State all written on recent activity
• No ANTHROPIC_* / CLAUDE_* environment variables set (checked in env, ~/.profile, ~/.bashrc, /etc/environment)
• Persists across killall + relaunch
• Persists across upgrade 1.32 → 1.37937.3
• Only re-authenticating clears it — consistent with server-side invalidation rather than local credential loss

Note

DevTools are disabled in the production build (Ctrl+Shift+I opens an incognito chat, F12 does nothing), so I couldn't capture the response body of the failing 403. Happy to provide it if there's a supported way to enable remote debugging.

Confirming this on Windows 11, on the same app build as the comment above — so it is not Linux-specific.

Environment

| | |
|---|---|
| OS | Windows 11 x64 |
| App | Claude Desktop 1.37937.3 (Electron 42.10.0, Node 24.18.1) |
| Account | Personal, no SSO, no Enterprise/Console organization |
| Browser | Chrome on the same machine, same account |

Same symptom

The desktop app demands a full interactive re-login roughly once a day. Throughout, claude.ai in Chrome on the same machine stays signed in with no interruption — the account session is alive and only the desktop app's auth is being invalidated. That matches the "browser sessions on the same machine persist for weeks; only the desktop app is affected" observation in the original report.

Independent evidence that this is not local credential loss

Ending every Claude process in Task Manager and relaunching the app immediately restores the session with no login prompt, so stored credentials do survive a full restart. That rules out a wiped credential store, a DPAPI/safeStorage failure, or a cleanup tool clearing the app data folder — and is consistent with the server-side auth_kind=session_stale_relogin redirect captured in the original report rather than anything happening on disk.

Also ruled out: an administrative session-length policy. This is a personal account with no Enterprise or Console organization, and that control is admin-only and can only shorten sessions.

Not yet verified on my side

I have not pulled %APPDATA%\Claude\logs\main.log to confirm that the same reason=elevated_auth&auth_kind=session_stale_relogin&from=logout redirect appears on Windows. Happy to add that if it would help.

Suggest widening the platform:linux label.

Windows 11 log evidence, following up on my comment above. Same server-side path as the Linux reports. Account, org and request IDs redacted.

Correction to my previous comment: this is not an MSIX/Store build. The standard Windows installer writes its logs to C:\Users\<user>\AppData\Local\Claude\Logs\main.log — LocalAppData, not Roaming. The %APPDATA%\Claude path I referenced does not exist on Windows.

The rejection, including the response body

error: '{"type":"error","error":{"type":"permission_error","message":"Session is not fresh enough to grant elevated access. Sign in again to continue.","details":{"error_code":"session_stale_relogin"}},"request_id":"<redacted>"}'

2026-08-21 07:55:21 [info] oauth authorize rejected with session_stale_relogin; sessionKey is valid but too old for the requested scope expansion
2026-08-21 07:55:21 [info] [oauth-v2] fresh exchange failed for orgId=<redacted> (session_stale_relogin)
2026-08-21 07:55:21 [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.

The previous comment notes that DevTools are disabled in the production build, so the body of the failing response couldn't be captured there. On Windows it is written to main.log in full — above.

The forced logout redirect, identical to the original report

topFrameUrl: 'https://claude.ai/login?returnTo=%2Fspace%2F<redacted>%3Freason%3Delevated_auth%26auth_kind%3Dsession_stale_relogin%26org_uuid%3D<redacted>&reauth=1&from=logout'

This line repeats at least 16 times within the same failure. The search that produced this excerpt was capped at 20 matches, so the true count may be higher.

What one line appears to pin down

sessionKey is valid but too old for the requested scope expansion

The session key is not expired — it is stated to still be valid. It is refused only for a scope expansion to elevated access, and the app's reaction to that refusal is a full from=logout teardown rather than a scoped re-auth of just the elevated request.

That would account for the browser-versus-app asymmetry several of us have reported: a browser session on the same machine never requests the scope expansion, so it never trips the freshness check and persists indefinitely, while the desktop app trips it on a roughly daily cadence and logs the whole session out.

If that reading is right there are two separable defects here: a freshness window on elevated-scope grants that is far shorter than the session lifetime, and the absence of graceful degradation when that grant is refused.

Description
The desktop app repeatedly prompts me to re-authenticate via Google (system browser opens /login/app-google-auth) roughly once per day, sometimes more, even though the underlying API OAuth token is still valid and cached correctly.

Environment

• OS: Kubuntu (KDE), Linux 6.8.0-138-generic
• Claude Code version bundled: 2.1.237
• Credential storage: KWallet (kwalletd5), confirmed working (kwalletd pre-flight: has-wallet)

Evidence from main.log

• API token cache in config.json loads and is reused successfully across restarts ("using cached token" repeatedly).
• Separately, "[Auth] Using system browser for: /login/app-google-auth" fires on a near-daily cadence (observed on 4 different days over 5 days of use).
• One occurrence was tied to: "AddSessionFile denied (untrusted_device); raised the re-login banner" / "DeviceRegistry: device not registered (no row-PK for this account)".

Expected behavior
Similar to other desktop AI clients (e.g. ChatGPT Desktop), the session should persist across app restarts without requiring a fresh Google login every day.

Question
Is there a way to mark this device as trusted persistently, or is this session lifetime intentional/configurable?

Correcting my earlier comment. On Windows, session_stale_relogin is not the daily signature — it appears exactly twice in my logs, both on 2026-08-21, with no recurrence in the eight days since, across a continuous 9-day log (main.log, 2026-08-21 07:55:18 → 2026-08-29 17:20:09, no rotation).

The daily marker is the teardown race, not the stale-session rejection

claudeURLHandler: login loadURL superseded (teardown race) — 8 occurrences over those 9 days:

2026-08-21 08:35
2026-08-23 12:22
2026-08-24 09:33
2026-08-25 08:32
2026-08-26 10:28
2026-08-27 09:19
2026-08-28 07:11
2026-08-29 17:00

Intervals between consecutive events: 51h47, 21h11, 22h59, 25h56, 22h51, 21h52, 33h49. Five consecutive intervals sit in the 21–26h band. The two outliers span days I did not open the app.

The wall-clock times drift across a ten-hour range (07:11 to 17:00) because the expiry does not surface when it occurs — it surfaces on first use afterward. That matches the "the failure fires on the first prompt sent, not at app launch" observation above, with a ~24h window rather than ~8h.

What this rules out

• Not a credential-storage failure. 669 successful [oauth] using cached token reads over the same period, plus 534 token lookups, with no lookup failures. The cache at config.json loads cleanly on every start.
• Not tied to app restarts. 6 cold starts in 9 days (08-21 07:55, 08-25 14:12, 08-26 07:55, 08-26 23:12, 08-27 13:21, 08-28 11:55), at times unrelated to the 8 logout events.
• Not triggered by scheduled tasks. I have daily Cowork tasks at ~07:00 and ~08:00; a task-driven cause would cluster at those times every day, and these do not.

On the elevated_auth rejection I posted earlier

It is real and the log excerpt stands, but at two occurrences on a single day it is a separate and much rarer event, not the daily cause. Apologies for conflating the two — the earlier comment overstated the connection.