### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? ## Summary In a cloud Cowork session with a connected folder on a macOS device, the device-to-cloud file staging call (`device_stage_files`) begins faili

[BUG] Cowork device bridge: file staging fails with 403 session_stale_relogin whenever the macOS user session hosting the desktop app is locked; heals on unlock, no re-auth needed

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 12, 2026

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?

Summary

In a cloud Cowork session with a connected folder on a macOS device, the device-to-cloud file staging call (device_stage_files) begins failing with HTTP 403 session_stale_relogin within about 60 seconds of the hosting macOS user session being LOCKED, and recovers within about 60 seconds of unlock, with no re-authentication performed at any point. All other device-bridge functions keep working while staging is down: device_bash, device_list_dir, and device_commit_files (cloud to device) are unaffected throughout. (Exact repro in Steps to Reproduce below.)

The error's remediation text is wrong in both of its claims: it says the user "must sign in again" (no sign-in is needed; unlocking the session is sufficient) and that "a sign-in banner has been raised" (the prompt appears inconsistently, and when it does appear it self-dismisses on its own once device trust re-validates after unlock, without being used).

Environment

Claude desktop app (macOS): 1.28929.0 (d1a6bc), built 2026-08-11 (updated the evening the incident began; the update proved unrelated)
macOS: 26.6.1 (25G76), Mac mini, Apple silicon
Cloud Cowork session started from the desktop app, one connected folder
The desktop app runs in a dedicated macOS user account; "locking" means that account's session (lock screen / fast user switch)

Timestamped evidence (2026-08-11/12, US Eastern; times verified against a live clock)

~00:15: session start; multiple stagings succeed.
Shortly after, the hosting user session was locked for the night; the first staging 403 followed within the hour. Staging then failed identically for ~7 hours while device_bash reads, device_list_dir, and a device_commit_files write all succeeded during the same window.
~07:40: user unlocked the session; staging succeeded with no re-auth.
Controlled re-test: pre-lock probe OK at 07:40; session locked; probe returned the 403 at 07:41:13 while a device_bash control succeeded; session unlocked ~07:43; probe OK at 07:43:51, again with no re-auth. The app displayed a sign-in prompt at this unlock which then disappeared on its own, unused, once staging had already recovered.

Impact

An unattended overnight session loses device-to-cloud file staging entirely whenever the hosting user locks the machine, which is the normal overnight state for an always-on machine.
The misdiagnostic message steers users toward sign-out/re-auth cycles, which are themselves risky with concurrent clients (single-use refresh-token rotation; see #54443 for that class).
The failure is silent from the device owner's perspective: nothing on the device surfaces it, and the in-session error actively misattributes it.

Notes

The asymmetry (staging alone dies; shell, listing, and cloud-to-device commits survive) suggests the staging/upload endpoint applies a device-trust freshness check the other bridge endpoints do not.

What Should Happen?

Either file staging should keep working while the hosting macOS session is locked (the rest of the device bridge does), or the error should state the actual condition ("the device's user session is locked") and clear on unlock, rather than instructing a re-sign-in that is not in fact required and referencing a sign-in banner that may not be visible.

Error Messages/Logs

HTTP 403 adding session file: session_stale_relogin
"File staging was denied because this device's sign-in is stale or the device is no longer trusted. The user must sign in again in the Claude desktop app on this device - a sign-in banner has been raised there. Tell the user, and do not retry staging until they have re-authenticated."

Steps to Reproduce

Start a cloud Cowork session from the macOS Claude desktop app with at least one connected folder.
Confirm staging works: have the session call device_stage_files on any small file inside the connected folder. It succeeds.
Lock the macOS user session that hosts the desktop app (lock screen or fast user switch). Leave the app running.
Within about 60 seconds, call device_stage_files on the same file again: it fails with HTTP 403 adding session file: session_stale_relogin (full text in Error Messages). In the same window, confirm the rest of the device bridge still works: device_bash and device_list_dir succeed, and device_commit_files still writes files to the device.
Unlock the macOS user session. Within about 60 seconds, device_stage_files succeeds again. No re-authentication is performed at any point.

Reproduced twice on 2026-08-11/12: an overnight lock produced a ~7 hour staging outage that ended within a minute of the user unlocking, and a controlled 3 minute lock/unlock cycle with probes reproduced both transitions (timestamps in What's Wrong).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude desktop app 1.28929.0 (d1a6bc), built 2026-08-11. The bug is in the Cowork device bridge (desktop app + cloud session); the Claude Code CLI is not involved in the repro, so claude --version is not applicable.

Platform

Other

Operating System

macOS

Terminal/Shell