[BUG] Remote Control sessions are archived on teardown and never unarchived, making them permanently invisible on mobile after a desktop auto-update
Preflight Checklist
- [x] I have searched existing issues. Related reports exist (#87335, #65838, #71873) but none identifies this root cause — see Related Issues below.
- [x] This is a single bug report
- [x] I am using the latest version available to me. Claude Desktop bundles its own Claude Code (
2.1.246at time of observation) and manages that version itself; the latest published npm version is2.1.250.
What's Wrong?
When the Claude Desktop app auto-updates and relaunches, it terminates every running Claude Code session process. Each session archives its Remote Control (cloud) session during teardown. Those sessions then appear only under the Archived filter in the mobile app and on claude.ai/code — they are gone from the default session list.
This happens with no user action: the affected sessions had no pull requests attached, were never manually archived, and auto-archive-on-inactivity was disabled. The desktop app's own log records no archive request for them, which indicates the archive is issued by the session process itself rather than by the app.
The state is not recoverable from the desktop side. Archiving propagates desktop → cloud, but unarchiving never propagates at all. Reopening a session locally makes it active again and reattaches it to its original bridge session id, yet the cloud session stays archived indefinitely.
Net effect: a routine background auto-update silently removes every open Remote Control session from mobile, permanently, and repeats on each release.
What Should Happen?
- A session terminated by an app update/restart should not be archived — it was not finished, abandoned, or closed by the user.
- Unarchiving or reopening a session locally should propagate an unarchive to the cloud session, so it returns to the default list.
At minimum, teardown caused by an app-initiated restart should set the existing skip-archive path rather than archiving.
Related Issues
This is filed separately because the root cause differs from each of these, and the mechanism below is not described in any of them.
- #87335 (open) — desktop app update breaks session continuity and the archive/resume UI cannot surface the session. Same trigger and a matching symptom, but no mechanism identified; that report is labeled
platform:windows. The teardown-archive behaviour documented here is a likely cause of what that reporter observed. - #65838 (open) — archive state is per-client and does not propagate between iOS and macOS. Adjacent to the propagation half of this report, from the opposite direction.
- #71873 (closed, not planned) — Remote Control session auto-archives while still active, attributed to a token-refresh race. This report describes a different trigger: archiving at process teardown when the app kills its own sessions, plus the missing unarchive propagation that makes the result permanent.
Error Messages/Logs
# Desktop app log — archive propagates (8 days of logs)
[LocalSessionManager] Requested CCR archive of 1 Remote Control bridge session(s)
for archived session local_<redacted>
-> 278 occurrences
# Unarchive never propagates
grep -c "CCR unarchive|unarchive.*bridge|bridge.*unarchive" -> 0
# ...despite local unarchives occurring
LocalSessions.unarchive: sessionId=local_<redacted>
Unarchived session local_<redacted>
-> 3 occurrences, none followed by a CCR request
[CCD] clearStaleResumeHandle session=local_<redacted> reason=clearSession
dropping cliSessionId=<redacted> unarchivedCliSessionId=undefined
# On the day the affected sessions were archived, the app requested zero archives.
# Session-process archive machinery (strings, claude 2.1.246):
archiveRemoteSession · teardown_archive_timeout_ms · archiveAbandoned
skipArchive · replBridgeSkipNextArchive · bridge_session_unarchive
Steps to Reproduce
- Enable Remote Control for all sessions (
remoteControlAtStartup: true, or Settings → Claude Code → Enable remote control by default). - Open several Code sessions in Claude Desktop. Confirm each logs
Remote control enabled: https://claude.ai/code/session_…and appears in the mobile app's session list. - Leave them open until the desktop app auto-updates and relaunches (ShipIt), terminating all session processes. Quitting the app reproduces the same teardown.
- In the mobile app, switch the session filter from All to Archived.
- Every previously live session is now archived — no PRs attached, none manually archived, no archive request in the desktop log.
- Reopen one of them on the desktop. It becomes active and reattaches to its original bridge session id.
- Observe it remains archived in the cloud. No unarchive is ever sent, and there is no desktop-side action that restores it.
Frequency: reproduced across two auto-updates within 22 hours.
Claude Model
Opus
Is this a regression?
I don't know
Version
Claude Code 2.1.246, bundled in Claude Desktop 1.37937.1
Operating System
macOS
Terminal/Shell
Other — Claude Desktop app (Code tab)
Additional Information
- Workaround: unarchive from the server side (mobile or web archived filter). The cloud is the only side that can reverse it.
- Sessions on a separate machine running
claude remote-controlin server mode are unaffected — they stay listed and connected for weeks — which isolates this to the desktop app's session lifecycle. - The teardown-archive link is inferred from timing plus the archive machinery named above; the archive/unarchive asymmetry (278 vs 0) is measured directly from the application log.