[FEATURE] Desktop: restore sidebar sessions when session metadata is lost (transcripts are intact)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

On Windows 11, Claude Desktop (Code tab) suddenly showed almost none of my ~186 sessions in the sidebar. The per-account metadata folder %APPDATA%\Claude\claude-code-sessions\<org>\<account>\ had been recreated (fresh timestamps, only a few new local_<uuid>.json files). I don't know what triggered it.

All the conversation data was still there and intact: every transcript in ~\.claude\projects\<project-slug>\*.jsonl, including its subagents and tool-results sidecar folders. Each transcript records "entrypoint":"claude-desktop", so it is clearly a Desktop session. The app just no longer knew about it.

Why recovering was hard

1. No import or rescan. The sidebar lists only sessions that have a local_<uuid>.json metadata file (with cliSessionId pointing at the transcript). A transcript without one is invisible, and nothing in the app finds or re-adopts it.
2. The CLI workaround doesn't restore the sidebar. claude --resume <id> reopens the conversation in a terminal, but it doesn't bring it back into Desktop.
3. The manual fix is fragile and undocumented. It needs:

• copying each transcript (and its sidecar folder) under a new ID;
• hand-writing a local_<uuid>.json modeled on an existing entry (cwd, title, createdAt/lastActivityAt, model, cliSessionId);
• fully quitting and restarting the app, because new entries aren't picked up while it runs.

1. Auto mode blocks the fix with no way to approve it. When I asked Claude to do the repair, the auto-mode safety check denied it as "Session Transcript Tampering". It did so again after I explicitly approved in chat, and no approval prompt was offered. I had to switch the session to manual mode before it could go ahead.

Losing the sidebar means losing months of working context (decisions, investigations, ticket history), even though the data is all on disk.

Proposed Solution

1. Re-adopt orphaned transcripts automatically. On startup (or from a "Restore sessions" menu item), find transcripts under ~/.claude/projects/ that came from Desktop but have no metadata entry, and offer to add them back. The transcripts already contain what's needed to rebuild an entry: cwd, custom title, timestamps, model and git branch.
2. Add an "Import session" action that takes a CLI session ID or a .jsonl path, so individual CLI sessions can also be brought into Desktop.
3. Protect the metadata. Find out why the folder was reset. Write entries atomically, keep a rolling backup, and if the folder is found empty or reset, rebuild it from the transcripts instead of starting over.
4. Pick up entries without a restart, or document that a full quit (including from the system tray) is needed.
5. Let the user approve blocked actions in auto mode. When the safety check blocks something the user explicitly asked for, offer a one-time approval prompt instead of a hard denial. At least name the setting to change.
6. Document the session storage layout (transcript vs. Desktop metadata), so people can recover without reverse-engineering it.

Alternative Solutions

Workarounds available today:

• claude --resume <session-id> in a terminal. The full scrollback is visible, but the session doesn't come back to the Desktop sidebar.
• Hand-writing local_<uuid>.json entries that point at copied transcripts, then fully restarting the app. This worked for all 186 sessions, but needs manual mode and knowledge of an undocumented format.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

I use Desktop daily across many long-running work threads (tickets, investigations, reviews). Some sessions span over a week and several compactions. After the sidebar lost its entries, I couldn't continue any of them from the app, even though every transcript was on disk. One "Restore sessions" action would have fixed it in seconds; it took a lengthy debugging session instead.

Additional Context

_No response_