[BUG] Cowork: device session force-logged-out every ~24–36h (elevated_auth / session_stale_relogin), breaking unattended automations
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Environment
- App: Claude Desktop (Cowork), appVersion
1.24012.1(updater staged1.24012.9), isPackaged - Platform: macOS, arm64 (MacBook Pro 2022 M1 Max), Node 24.18.0
- Account: individual account, email/magic-link sign-in
- Org UUID:
b092139f-0744-4a89-9612-ac7fde936c0d - Cowork session affected:
cse_01CqprSFr8A7v1ApeqFqhRBK(session with computer/browser access, used by scheduled automations)
Summary
The claude.ai session inside the desktop app is invalidated server-side roughly every 24–36 hours with reason=elevated_auth&auth_kind=session_stale_relogin. The app then sits on the login page until I manually re-authenticate via an emailed magic link. While logged out, the device is offline to Cowork, so any scheduled automation that needs this Mac's browser fails.
The machine is not the cause: power settings prevent sleep on AC, the app never crashed (zero entries in ~/Library/Logs/DiagnosticReports all week), the auto-updater performed no restarts between Jul 22 and Jul 26, and the most recent forced logout occurred at 19:03 local time while the machine was awake and in active use.
Forced logout timeline (from ~/Library/Logs/Claude/main.log)
| # | Date/time (local) | Evidence |
|---|---|---|
| 1 | 2026-07-22 05:58 | line 168: topFrameUrl: 'https://claude.ai/cowork/cse_01Cqpr…?reason=elevated_auth&auth_kind=session_stale_relogin&org_uuid=b092139f-…' |
| 2 | 2026-07-23 21:08 | line 6463: topFrameUrl: 'https://claude.ai/login?returnTo=%2Fcowork%2Fcse_01Cqpr…session_stale_relogin…&reauth=1&from=logout' |
| 3 | 2026-07-25 03:57 | line 11201: same login?…session_stale_relogin…&from=logout URL |
| 4 | 2026-07-26 19:03 | line 16404: same login?…session_stale_relogin…&from=logout URL |
Each logout is followed a few minutes later by a https://claude.ai/magic-link#… load (manual re-login) at lines 6496, 11226, 16440, after which the device bridge recovers immediately:
2026-07-26 19:07:42 [info] [remote-tools-device] device registered — draining to refresh row PK
2026-07-26 19:07:43 [info] [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/…/andreys022m1max-cable-rcn-com/bridge
2026-07-26 19:07:44 [info] [remote-tools-device] authenticatedIntervals between forced logouts: ~39h, ~31h, ~39h — consistent with a ~24–36h server-side session TTL, with the logout only being observed at next window focus.
Chronic accompanying symptom (from claude.ai-web.log)
remote_cowork.sign_for_session_header_failed fires continuously (dozens of occurrences from 2026-07-17 through 2026-07-26), including hours before each forced logout:
2026-07-26 18:01:08 [warn] [LOCAL_SESSION] remote_cowork.sign_for_session_header_failed {"errName":"Error","sessionId":"cse_01CqprSFr8A7v1ApeqFqhRBK","orgUuid":"b092139f-0744-4a89-9612-ac7fde936c0d"}
2026-07-26 19:03:45 [warn] Blocked permission check { … topFrameUrl: 'https://claude.ai/login?returnTo=…session_stale_relogin…&from=logout' }Ruled out
- Crash: no Claude entries in
~/Library/Logs/DiagnosticReports(checked incl.Retired/). - Auto-update restart:
main.logshows a singleStarting appon Jul 22 05:58; updater merely polled ("Staged version … is still current") for the rest of the week. - Sleep: macOS "Prevent automatic sleeping on power adapter when the display is off" is enabled;
event-loop-stall [likely sleep]entries exist only during overnight power-nap windows and do not coincide with logouts #2–#4 (e.g., #4 at 19:03 during active use — aWindow focusedSkillsPlugin poll runs 3 seconds before the login redirect appears).
Impact
Scheduled Cowork automations that require this device's Chrome browser fail whenever the session is in the stale-logout state — i.e., a guaranteed outage every 1–2 days for a paying (Max) customer, silently, until manual magic-link re-login.
Expected behavior
Either (a) the desktop app silently refreshes/re-elevates the session without interactive login (it demonstrably still holds valid OAuth tokens — [oauth-v2] using cached token succeeds and the device bridge re-authenticates instantly once the web session is restored), or (b) session lifetime for a trusted, previously-elevated device is long enough not to break daily automations, or at minimum (c) the user is notified (push/email) that the device went offline pending re-login.
Related: #36807 (remote control sessions should persist without interactive re-login).
Questions for triage
- Is a 1-day session-duration policy being applied to this account (single personal org — no Team/Enterprise membership known to the user)? If so, from where?
- Is
sign_for_session_header_failedthe trigger or an independent bug?
Full main.log and claude.ai-web.log available on request (magic-link tokens redacted above).
What Should Happen?
The desktop app should keep the Cowork device online without manual re-login: either silently refresh/re-elevate the claude.ai session using the valid OAuth tokens it already holds (the device bridge re-authenticates instantly once the web session is restored, proving the credentials are fine), or apply a session lifetime for a trusted, previously-elevated device that is long enough not to break daily automations. At minimum, notify the user (push/email) that the device went offline pending re-login instead of failing silently.
Error Messages/Logs
~/Library/Logs/Claude/main.log:
2026-07-26 19:03:45 [warn] Blocked permission check {
permission: 'background-sync',
requestingOrigin: 'https://a.claude.ai/',
requestingUrl: 'https://a.claude.ai/isolated-segment.html?v=20d9aa4742',
isMainFrame: false,
topFrameUrl: 'https://claude.ai/login?returnTo=%2Fcowork%2Fcse_01CqprSFr8A7v1ApeqFqhRBK%3Freason%3Delevated_auth%26auth_kind%3Dsession_stale_relogin%26org_uuid%3Db092139f-0744-4a89-9612-ac7fde936c0d&reauth=1&from=logout'
}
2026-07-26 19:07:42 [info] [remote-tools-device] device registered — draining to refresh row PK
2026-07-26 19:07:43 [info] [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/…/andreys022m1max-cable-rcn-com/bridge
2026-07-26 19:07:43 [info] [oauth-v2] using cached token for orgId=b092139f-0744-4a89-9612-ac7fde936c0d
2026-07-26 19:07:44 [info] [remote-tools-device] authenticated
~/Library/Logs/Claude/claude.ai-web.log:
2026-07-26 18:01:08 [warn] [LOCAL_SESSION] remote_cowork.sign_for_session_header_failed {"errName":"Error","sessionId":"cse_01CqprSFr8A7v1ApeqFqhRBK","orgUuid":"b092139f-0744-4a89-9612-ac7fde936c0d"}
(same warning repeats dozens of times daily from 2026-07-17 through 2026-07-26)Steps to Reproduce
- On macOS, sign in to the Claude desktop app (email/magic-link account) and start a Cowork session with computer/browser access bound to this device.
- Leave the app running with the Mac awake (automatic sleep on power adapter disabled).
- Wait roughly 24–36 hours — no user action needed.
- The embedded claude.ai session is invalidated server-side: the app lands on
claude.ai/login?returnTo=…&reason=elevated_auth&auth_kind=session_stale_relogin&…&from=logout. - The device is now offline for Cowork; any scheduled automation requiring this device's browser fails silently until manual re-login via emailed magic link.
Observed 4 times in 5 days (2026-07-22 05:58, 2026-07-23 21:08, 2026-07-25 03:57, 2026-07-26 19:03 local). Full evidence in the description above.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Desktop app 1.24012.1 (bundled Claude Code/CCD 2.1.217) — not a CLI install
Platform
Other
Operating System
macOS
Terminal/Shell
Other
Additional Information
Note on the form fields: this bug is in the Claude desktop app (Cowork), not the CLI, so "Claude Code Version", "Platform", and "Terminal/Shell" don't map cleanly — the app is Desktop 1.24012.1 (Electron 42.x) with bundled CCD 2.1.217 on macOS arm64, account is a claude.ai Max subscription (not API). Terminal/Shell = Other/N-A.
The account belongs to a single personal org; no known Team/Enterprise membership that would explain a 1-day session-duration policy (per https://support.claude.com/en/articles/13163631-configuring-session-security-settings, the shortest org policy wins — happy to be corrected if support sees one attached to this account).
3 Comments
I'm experiencing what appears to be a very similar issue on Windows using Warp and OAuth ("Claude Account with Subscription").
However, one detail in my case seems different:
My
credentials.jsonstill contained arefreshTokenExpiresAtvalue approximately 18 days in the future, while bothaccessTokenandrefreshTokenhad already been cleared, forcing a complete/login.I've opened a separate issue with the full timeline and credential details for investigation:
#83464
I'm mentioning it here in case both issues share the same root cause.
Confirming this on macOS as a second, independent case — and on a newer desktop build than the original report, so it is not fixed.
Environment
Measured interval matches the reported 24–36h band
~/Library/Logs/Claude/main.logcurrently covers Jul 31 – Aug 5. Within that window there are 4 distinct forced-relogin events (58 log lines, but the same redirect URL is emitted repeatedly per event):The 32.2h gap sits squarely in the ~31–39h range reported above. Two different Cowork sessions were hit (
cse_018yogtmcjAAS5JzsvJmKpR8,cse_01JHDAj72wZsZHJBW7xiCaLJ), so it is not session-scoped.Identical redirect signature, including
from=logout:The
sign_for_session_header_failedprecursor is also presentWorth noting it lives in a different log file than the relogin events —
claude.ai-web*.log, notmain.log. 42 occurrences, spanning two log rotations and going back to at least Jul 16:So the warning has been firing chronically for ~3 weeks here, consistent with OP's observation that it precedes each logout.
User-facing symptom from mobile
The part that makes this more than a background annoyance: on the mobile app the failure surfaces as a banner —
— with no way to recover from the phone. The desktop app is open, awake, and holds valid OAuth tokens; it simply cannot refresh the web session without an interactive login on the Mac. That means the entire remote-work path (phone → desktop → local files) is dead until you are physically back at the machine.
This is the concrete impact for me: it makes travelling without the laptop unreliable. A workflow that previously worked for weeks now breaks roughly every day and a half, and there is no way to know it has broken until you try to use it.
Re-auth attempts, all ineffective
Same list as OP, independently reproduced: signed out on all devices, signed back in on the Mac first and only then on phone and tablet, desktop app sign-out/sign-in, app updated to current. The banner returns within ~24–36h regardless. The ordering of sign-ins makes no difference.
Supporting the original asks
Of the three remedies proposed above, (c) is the cheapest and would already remove most of the pain:
Happy to supply full logs or request IDs if that helps triage.
Third independent confirmation, on a newer app version than either report above.
Environment
Recurrence pattern from
~/Library/Logs/Claude/main.logFirst forced-relogin event per day, matching the
elevated_auth/session_stale_reloginsignature from the OP and @Stevenk88:Gaps land in the same ~16–30h band already reported. Once triggered, the app retries
oauth tokenacquisition roughly every 30 seconds and fails every time with the identicalsession_stale_reloginerror until I manually sign out/in — over 1,000 identical failed retries logged during these windows. No amount of quitting/relaunching prevents recurrence; it's on the same ~24–36h clock regardless.Happy to provide raw log excerpts or request IDs if useful for triage.