Desktop app session list can't adopt existing local CLI sessions — sidebar left empty after Max→Teams account migration
What happened
Migrated a personal Max account to a Teams org (same email, official migration flow). All Claude Code transcripts remained intact on disk under ~/.claude/projects/ (78 sessions, ~78 MB), and the terminal CLI's --resume picker lists and resumes every one of them under the new login. But the desktop app's sidebar shows none of them, and /resume inside a desktop-app chat shows no chats — the app's session registry appears to be account/org-scoped and separate from on-disk history, with no import path.
What I tried
- Resuming sessions from the bundled CLI, both interactively and headlessly (
claude -p --resume <id>): the transcripts continue fine on disk, but the sessions never appear in the desktop app. - The desktop app's own
/resumepicker in a fresh chat: empty ("no chats"), while the terminal picker in the same folder lists 32. - The
ccd_session_mgmtchannel rejects the on-disk session IDs with "Session not found".
The docs confirm the behavior: sessions.md says the desktop app, web, and VS Code extension "each maintain their own session history" — but there's no documented way to bridge them, and the account-migration docs don't warn about this.
Expected
Either of:
- The desktop app offers to adopt/display local CLI sessions for a trusted project folder (they're already in the standard
~/.claude/projects/location the app itself writes to), or - The account-migration flow warns that the app's session list won't carry over.
Right now the reassurance "your history is local, nothing is lost" is technically true but misleading when the app UI is the primary way a user browses that history — the data survives the migration, the ability to see it in the app does not.
Environment
- Windows 11 Pro (10.0.26200)
- Desktop app bundling Claude Code 2.1.246
- Trigger: personal Max → Teams org migration (same email)
Related
Same symptom (sidebar empty, disk data intact) with different triggers: #83730 (forced reinstall), #87710 (fresh install), #89544 (reinstall), #87423 (app restart), #86277 (data reset). This report adds the account-migration trigger and the feature ask: a supported way for the app to adopt existing local transcripts.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Same symptom on Windows, different trigger: a fresh-machine migration (not an account migration) via a custom backup/restore script —
.jsonltranscripts copied straight into~/.claude/projects/<encoded-path>/.claude --resumefrom the terminal lists and resumes every restored session correctly; the desktop app sidebar and its own/resumepicker showed none of them, same as reported here.Found a partial workaround worth recording: running
claude --resumeinteractively in a real terminal inside the trusted project folder, while the desktop app is running, does make that session appear in the app's sidebar — but only while the terminal process stays alive. Closing the terminal causes the app to auto-archive the session (a toast appears); manually undoing the archive from the toast makes it stick permanently after that. So there is a path to "adopt" a session today, it's just entirely manual and non-obvious (per-session, requires a live terminal + catching a toast).Also observed as a side effect: after that resume,
~/.claude.json'sprojects["<path>"]entry gains alastSessionIdfield plus cost/duration/token metrics for that session — it didn't have this before. Given #81835 confirms the real index is an Electron IndexedDB store, this is probably just a bookkeeping artifact of a live IPC connection between the CLI process and the running desktop app, not the actual discovery mechanism — but it might be a useful breadcrumb for whoever investigates.Separately, resumed sessions landed under "Other" in the sidebar instead of their project's group, matching #89781 — including the same double
.claude.jsonentry pattern (one path keyed with\, one with/) reported there.There are two separate questions in this migration: whether the 78 transcripts still have matching Desktop metadata, and whether that metadata is under the account/organisation pair the new login reads. The CLI can resume a JSONL even when the Desktop sidebar has no record for it.
I built a toolkit for this file-layer check:
diagnose.pyinBasedGPT/claude-code-session-recoveryinventories the Desktop metadata and~/.claude/projects/transcripts, then prints the exact command if it finds orphaned transcripts. Run it on the Windows machine and review the dry-run before applying anything. If it reports more than one account/organisation pair, preserve every populated pair and do not move records based on counts alone.That separates a recoverable
sessions_missing_from_session_listcase from an account/organisation rotation that needs confirmation. Keep a copy of the metadata and transcript directories before any write.Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)
Hey InbalCodes,
The fresh-machine reproduction makes the boundary clearer: the CLI can see the copied transcripts, while the Desktop app still lacks a durable session-list record. The live terminal behaviour looks like registration while a process is active, not import of the on-disk set.
I built a toolkit for this case:
diagnose.pyinBasedGPT/claude-code-session-recoverychecks the transcript and Desktop metadata layers and prints the exact command for orphaned transcripts. Run it on the restored Windows machine, review the dry-run, and apply only with Desktop fully quit. Compare the result withclaude --resumeafter restart; that will show whether the registration survived instead of relying on the temporary live session.Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)