[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
&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`.

2. **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.

3. **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.

4. **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.

5. **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=
```

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.

Start by reproducing the Cowork flow after the reported 24–48 hour interval and inspect ~/.config/Claude/logs/main.log around the auth_kind=session_stale_relogin redirect. Compare the Cowork authentication path with regular chat and the standalone CLI. Done means opening Cowork no longer drops the full desktop session, or the freshness requirement is handled as a scoped re-authentication.

由索引模型根据 Issue 内容生成。