[BUG] Cowork forces a full account logout (auth_kind=session_stale_relogin) roughly every 24-48h on Linux desktop

Summary

On Claude Desktop for Linux, opening a Cowork session periodically kicks the app back to a full login screen. The redirect URL shows this is a server-side step-up ("elevated auth") requirement, not a local credential-storage failure:

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

Note from=logout: this is not a scoped re-auth for the Cowork surface only — the whole desktop session is dropped and the user has to run the full OAuth flow again (external browser + hCaptcha) before anything works.

This happens every ~24-48h of continuous use, which for anyone using Cowork daily means re-logging in every single day, sometimes twice.

Environment

| | |
|---|---|
| App | claude-desktop 1.32885.1 (official .deb from downloads.claude.ai/claude-desktop/apt/stable, latest available) |
| Electron | 42.9.2 |
| OS | Pop!_OS 24.04 LTS |
| Desktop | GNOME Shell 46.0, Wayland (--ozone-platform=wayland) |
| Account type | Personal (1P deployment, deploymentMode: "1p"), Google OAuth login |
| Secret storage | gnome-keyring 46.1, libsecret-1-0 0.21.4, pam_gnome_keyring active in gdm-password, autologin disabled |

Observed occurrences

From ~/.config/Claude/logs/main.log (deduplicated; each event floods the log with ~50 identical Blocked permission check warnings whose topFrameUrl carries the redirect):

2026-08-16 12:49:47   auth_kind=untrusted_device        (initial device enrollment)
2026-08-18 12:38:24   auth_kind=session_stale_relogin
2026-08-19 09:52:56   auth_kind=session_stale_relogin

Interval between forced logouts: ~48h, then ~21h.

Why this is not a local credential-storage problem

This is the part I want to flag, because the obvious triage path ("Linux keyring is broken, cookies aren't persisting") does not apply here. I verified each of these on the affected machine:

1. Cookies are encrypted with the real keyring key, not the insecure fallback. Every row in ~/.config/Claude/Cookies carries the v11 prefix (gnome-keyring/libsecret backend). No v10/peanuts fallback anywhere. Local State shows os_crypt.portal.prev_init_success: true.

1. The cookie store survives restarts. Cookies created on 2026-08-16 (anthropic-device-id, ajs_anonymous_id, __Host-ant_trusted_device) were still present and decryptable on 2026-08-19, across multiple app and machine restarts.

1. Nothing is expiring on its own. sessionKey is issued with a 28-day expiry. __Host-ant_trusted_device runs to 2026-11-14. The forced logout happens long before either.

1. The logout occurs mid-session, not at startup. On 2026-08-19 the app started at 08:31 and ran normally for 81 minutes; the logout fired at 09:52 the moment a Cowork session was opened. That rules out any race between app launch and the keyring/D-Bus secrets service.

1. The OAuth token cache is intact. Immediately before the logout, the log shows successful token reuse:

``
2026-08-19 09:52:21 [info] [oauth] using cached token for orgId=<redacted>
``

So the client had valid, decryptable, unexpired credentials, and the server chose to invalidate the session anyway when Cowork requested elevated auth.

Expected behaviour

One of the following:

• If the session-freshness requirement is intentional for Cowork (which is reasonable — Cowork has filesystem access to the user's machine), then scope the step-up to Cowork and make it a re-authentication, not a from=logout that tears down the entire desktop session. Re-confirming identity to open Cowork is fine; being signed out of Claude entirely is not.
• If it is not intentional, the session should refresh silently the way it does for regular chat, cloud-hosted Claude Code, and the standalone CLI.

Either way, the freshness window should be documented, and ideally configurable, so users know what to expect instead of experiencing it as a random daily logout.

Actual behaviour

Full account logout, requiring the complete OAuth round trip through an external browser plus an hCaptcha challenge, roughly once a day.

Reproduction

1. Sign in to Claude Desktop on Linux and enrol the device (Cowork with a connected folder).
2. Use the app normally for 24-48h.
3. Open a Cowork session.
4. The app redirects to /login?...reason=elevated_auth&auth_kind=session_stale_relogin&reauth=1&from=logout and the session is gone.

Related

• #82721 — local Claude Code integration in Desktop forces re-auth every ~24h (reporter notes Cowork was not affected for them; this issue is the Cowork-side counterpart)
• #80494 — Claude Desktop on Linux requires re-login after reboot
• #28302 — frequent re-authentication, multiple times per day

Happy to provide the full main.log excerpt (redacted) or run any additional diagnostics on the affected machine.