[BUG] Desktop app reinstall breaks session continuity — archive/resume UI fails to surface existing sessions

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 17, 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?

Title

Desktop app reinstall breaks session continuity — Remote Control, Archive, and session history all fail to recover an existing session

Body

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

After updating the Claude Code desktop app, my in-progress session ("frontend UI implementation," a Remote Control session I was steering from my phone) stopped working, and recovering it required a lengthy manual workaround. Filing this because at no point did the product offer a clear, working path back to my own recent session — the UI silently failed at several different points.

Steps to reproduce

  1. Run a Claude Code session on a Windows desktop with Remote Control enabled, controlled from the Claude mobile app.
  2. Update the desktop app (in my case this led to a full uninstall/reinstall of the app, having misunderstood guidance to remove a conflicting npm install — but the app's own update flow should not require or invite this).
  3. Reopen the desktop app.

What happened

  • The phone session immediately showed "Remote Control disconnected — Claude Code on the computer that runs this session is no longer connected." Clicking "View details" only repeated the same message with no further diagnostic info.
  • On the desktop app, the original session appeared locked — no way to send /remote-control or otherwise reactivate it from within the session itself.
  • I could not find a Remote Control toggle in the location the docs describe generally ("Settings > Claude Code") in a form that applied per-session — only a global "Connect new sessions to Remote Control" toggle, which (per issue #60356) is already known not to reliably apply even to new sessions.
  • I archived the locked session to try to start fresh. After archiving, the project itself disappeared from the desktop app UI entirely — not just the session.
  • I went looking for the archived session/transcript on disk. %AppData%\Claude\claude-code-sessions\<org-id>\<user-id>\ contained no session files at all for this project (only an unrelated scheduled-tasks.json).
  • The actual transcript data was eventually found safe on disk under ~/.claude/projects/projectXfolder\ (as .jsonl files) — proving the underlying data survived the update/reinstall, but the desktop app's session index/UI had no idea it existed.
  • Separately, on the phone, the archived session became visible and could be manually unarchived from there — restoring visibility of the chat history on mobile — but attempting to send a message returned "Remote control session is offline. Reconnect or run /remote control to start a new session," and no reconnect path worked from the phone side either.
  • I ultimately had to: locate the correct project folder manually via dir in a terminal (its on-disk name, "project-X," didn't match the sanitized folder name shown in the sessions directory, open the project fresh via the desktop app's folder picker, start an entirely new session, and manually prompt that new session to read the old .jsonl transcript off disk and summarize the prior context — as the only way to avoid re-doing prior work.
  • Along the way, typing /remote-control in the new session returned "/remote-control isn't available in this environment" — with no explanation of whether Remote Control was active or not (it turned out to already be connected automatically, but the red warning text strongly implied a failure).

Environment

  • OS: Windows
  • Claude Desktop app (auto-update channel)
  • Claude Code (bundled with Desktop app)
  • Plan: Pro
  • Remote Control used via Claude mobile app (iOS/Android)

Additional notes

This took an extended troubleshooting session to resolve and required manually locating files in %AppData% and ~/.claude/projects/ — well beyond what a typical user should need to do to recover a session after a routine app update. Screenshots of each failure state (disconnected banner, locked session, archived session on phone, folder structure on disk, /remote-control error) are available and can be attached on request.

What Should Happen?

  • A desktop app update or reinstall should never orphan an existing session's visibility in the UI when the underlying transcript data is intact on disk (as confirmed it was in ~/.claude/projects/).
  • Archiving a session should not cause its parent project to disappear from the UI.
  • There should be a single, reliable, clearly-labeled way to reconnect Remote Control to a specific existing session — not a global toggle of uncertain effect (see #60356) plus a slash command that returns an ambiguous/alarming error message.
  • If /remote-control is deprecated or unnecessary in the desktop app environment, it should say so plainly (e.g., "Remote Control is managed automatically in this environment and is already active") rather than the current red "isn't available in this environment" text, which reads as an error/failure.
  • Archived sessions should be recoverable/resumable from either the desktop app or the mobile app, with consistent state between them (currently the phone allowed unarchiving and displayed history, but had no way to reconnect a live session; the desktop app showed no path to the archived session at all).

Error Messages/Logs

"Remote Control disconnected"

Steps to Reproduce

already listed above

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude 1.30096.5 (6e1346) 2026-08-14T21:58:49.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗