[BUG] Claude Code project/session sidebar empty after reinstalling Claude Desktop, despite intact local session history

Same issue here, confirming it's not resolved.

Environment:

• Claude Desktop (Windows, MSIX)
• Claude Code CLI updated from 2.1.114 → 2.1.237 during troubleshooting
• OS: Windows 10/11

Steps that happened:

• Claude Desktop crashed via a broken claude:// redirect link when authorizing a connector (Cloudflare)
• Reinstalled Claude Desktop clean (uninstall + reinstall via claude.ai/download)
• Sessions sidebar in the Code tab shows "Les sessions que vous démarrez apparaîtront ici" (empty) for all reconnected project folders
• Confirmed via PowerShell that all .jsonl session transcripts are fully intact under ~/.claude/projects/ (multiple sessions, several MB each, most recent same day)
• Reselecting the parent project folder (not just a subfolder) in the app did not fix it
• Fully quitting the app (checked system tray) and reopening did not fix it
• Updating the CLI itself (claude update, 2.1.114 → 2.1.237) did not fix the Desktop sidebar

Workaround that works 100%: opening a plain PowerShell terminal, cd into the project root, running claude, then /resume — this correctly lists and reopens all historical sessions. So this confirms it's purely a Desktop UI/indexing bug, not a CLI or data issue.

Would be great to get this prioritized — right now the Desktop app is unusable for continuity across projects without falling back to the raw CLI.

I hit this exact issue after a Claude Code crash followed by a reinstall.

Environment:

Windows 11
Claude Code Desktop app (native, not the CLI-only install)

What happened:

Claude Code crashed during a session.
Reinstalled Claude Code.
After reinstall, the sidebar showed the project's session list as empty / only new sessions created after the reinstall — none of the prior conversations appeared, and one stale entry showed up filed under "Other" instead of the correct project group.
Clicking "Archive" on the stale "Other" entry made it disappear with no way to recover it from the Archived list (consistent with it being an orphaned pointer with no backing session record, rather than a real archive operation).

Confirmed the underlying data was NOT lost:
I checked %USERPROFILE%\.claude\projects\<project-slug>\ directly and found the .jsonl transcript files for all prior sessions still fully intact on disk (one of them ~10.8MB / 953 user turns). None of these appeared via the app's session list or sidebar.

Confirmed --resume still works, sidebar index does not update:

claude --resume <session-id>

correctly targeted the orphaned session ID (it did not report "session not found" — it only failed on an unrelated auth issue in my non-interactive test environment). So the session data and its ID are fully intact; only the app's own session-index/sidebar is out of sync with what's on disk.

/doctor does not catch or fix this:
Ran /doctor in a fresh session hoping it would rebuild the index. It completed cleanly (checks 0-6, 9 passed, applied an unrelated update + a settings change) but did not detect or address the missing/orphaned sessions at all — this failure mode doesn't appear to be in its checklist.

Summary: this looks like the session-index/sidebar re-population step doesn't run (or doesn't fully run) after a fresh install/reinstall on Windows, even though the underlying .jsonl session files are completely intact. --resume <id> is currently the only way back into a session once this happens; there's no supported way to get it to reappear in the sidebar.

I hit this exact case and found where the sidebar actually reads from. It's fixable by hand, and the mechanism explains every symptom reported in this thread.

The sidebar does not read ~/.claude/projects/. That's why intact transcripts change nothing, why re-selecting the project folder does nothing, and why /doctor comes back clean — none of them touch the thing that's actually empty. The sidebar is built from a separate registry, one JSON file per row:

Windows:  %APPDATA%\Claude\claude-code-sessions\ACCOUNT_ID\ORG_ID\local_UUID.json
macOS:    ~/Library/Application Support/Claude/claude-code-sessions/...  (same layout)

ACCOUNT_ID and ORG_ID are the two nested folders already there; local_UUID.json is one file per sidebar row. Each file links a row to a transcript through a cliSessionId field, which is just the .jsonl filename. A reinstall gives you a fresh app profile, so that folder comes back empty. Every transcript survives — the index is what was lost.

@Orffyrus-Qc, this answers #88065. You looked for sessions-index.json under ~/.claude/projects/, didn't find one, and concluded there was no local file you could hand-edit. That file belongs to the VS Code extension (#66499), not to the desktop app — on my machine sessions-index.json does not exist anywhere and the desktop sidebar works fine. The file you wanted is local_UUID.json in the path above.

The rest of the thread falls out of the same fact:

• claude --resume works, sidebar doesn't update (@skana3111-a11y) — different sources. The CLI reads transcripts; the sidebar reads the registry.
• The app's own /resume is empty at the same time the terminal's works. Mine said "no Claude Code sessions found on this computer" with 8 transcripts on disk, minutes after claude --resume in a terminal listed them all. Same command, different source depending on how the session was launched. Worth knowing, because the in-app picker looks like proof of data loss and isn't.
• /doctor can't catch it (@Gibyeng) — it checks config and install health, not this registry.
• The "Other" entry that archived into nothing (@Gibyeng) — your read looks right to me: a registry file whose cliSessionId no longer resolves is a pointer with nothing behind it, so archiving had nothing to move.

Confirming it's this

Open the folder above. Zero local_*.json files — or only the session you have open right now — and that's the whole bug. Any entry the app has written since will show a cliSessionId matching a .jsonl filename under ~/.claude/projects/. That one field is the entire link.

Getting them back

Write one local_UUID.json per transcript. These fields were enough:

{
  "sessionId": "local_PUT_A_NEW_UUID_HERE",
  "cliSessionId": "the .jsonl filename, without the extension",
  "cwd": "the project path",
  "originCwd": "the same project path",
  "title": "what you want shown in the sidebar",
  "titleSource": "custom",
  "createdAt": 1750000000000,
  "lastActivityAt": 1750000000000,
  "lastFocusedAt": 1750000000000,
  "isArchived": false
}

Fully quit the app and relaunch — it reads this registry only at startup, and closing the window isn't enough (check the tray). I got 8 conversations back, oldest from June, full history, resumable in place, and they persist across restarts now.

Script

Back up the folder first. This only creates entries that are missing — it never modifies or deletes an existing one. Tested both against a populated registry and against a completely empty one, which is the post-reinstall case.

import json, os, uuid, glob
from datetime import datetime, timezone

REG = glob.glob(os.path.join(os.environ["APPDATA"], "Claude",
                             "claude-code-sessions", "*", "*"))[0]
ms = lambda s: int(datetime.strptime(s[:19], "%Y-%m-%dT%H:%M:%S")
                   .replace(tzinfo=timezone.utc).timestamp() * 1000)

known, tpl = set(), {}
for f in glob.glob(os.path.join(REG, "local_*.json")):
    d = json.load(open(f, encoding="utf-8"))
    if d.get("cliSessionId"):
        known.add(d["cliSessionId"])
        tpl = d                       # an entry the app wrote = best template

for jsonl in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    cli = os.path.basename(jsonl)[:-6]
    if cli in known:
        continue
    lo = hi = cwd = title = None
    for line in open(jsonl, encoding="utf-8", errors="replace"):
        i = line.find('"timestamp":"')
        if i >= 0:
            ts = line[i + 13:i + 37]
            if ts.startswith("20"):
                lo = ts if lo is None or ts < lo else lo
                hi = ts if hi is None or ts > hi else hi
        if (cwd is None and '"cwd":"' in line) or '"customTitle"' in line:
            try:
                d = json.loads(line)
            except ValueError:
                continue
            cwd = cwd or d.get("cwd")
            title = d.get("customTitle") or title
    if not (lo and cwd):
        continue
    sid = "local_" + str(uuid.uuid4())
    e = dict(tpl)
    e.update(sessionId=sid, cliSessionId=cli, cwd=cwd, originCwd=cwd,
             title=title or cli[:8], titleSource="custom", isArchived=False,
             createdAt=ms(lo), lastActivityAt=ms(hi), lastFocusedAt=ms(hi),
             bridgeSessionIds=[], enabledMcpTools={})
    json.dump(e, open(os.path.join(REG, sid + ".json"), "w", encoding="utf-8"),
              ensure_ascii=False, indent=2)
    print("added:", title or cli)

On macOS, swap the REG line for the ~/Library/Application Support/Claude/... path. To undo, delete the files the run created.

Caveats, honestly

• Unsupported. This is the app's private data directory; the format can change.
• Verified on one machine: Windows 10 Pro 19045, Claude desktop MSIX, CLI 2.1.246. macOS follows the same layout but I could not verify it.
• It restores the index, not content. If a transcript isn't on disk, this won't help.
• Don't derive cwd from the folder name under ~/.claude/projects/ — that encoding turns both path separators and spaces into -, so My Project and My/Project are indistinguishable there. Read cwd from inside the transcript, like the script does. My first attempt got this wrong and produced a path that doesn't exist.
• The app log line LocalSessionManager ... existingSessions=N stayed at 0 even after the fix worked. Don't use it to check whether it took — look at the sidebar.

The supported fix is presumably for the app to fall back to scanning ~/.claude/projects/ when the registry is empty, since the transcripts are the source of truth and are already sitting right there.

---

I’m not a programmer... I’m just someone who got desperate and searched everywhere possible for a solution. Claude wrote all this text, and I just tried to review it. I apologize if this doesn't work in your version of Claude Code... it worked for me, and I did my best to share it with you.

The fix is here!

Huge thanks to OBebel for providing the original method and script.

Using that foundation, Claude and I built an application that automates the restoration of Claude Desktop sidebar session history after a Windows reinstallation. It can also repair broken or missing session paths caused by drive-letter changes.

GitHub:
https://github.com/Orffyrus-Qc/claude-session-repair

If you run into any problems, add #Guillaume3702 on Discord. Once I accept your request, I’ll contact you and try to help.

Disclaimer: I’m not a professional programmer, and this project is an independent community tool. I’m not affiliated with, endorsed by, or associated with Anthropic in any official capacity.

Correction to my comment above. @Orffyrus-Qc found a case it gets wrong, and it fails silently, which is the worst way to be wrong.

The desktop app ships as MSIX, and MSIX virtualizes AppData. Whether %APPDATA%\Claude is the live path depends on your install history:

• If the real %APPDATA%\Claude folder existed before the MSIX install, that path is live. I verified this on mine by writing a marker file into %APPDATA%\Claude\claude-code-sessions and reading it back from the virtualized view. Same storage, two windows onto it, and the folder is not a junction.
• If it did not pre-exist, the live registry is under the package instead:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-sessions\

In that second case, following my instructions writes JSON into a folder the app never reads. Nothing errors. The sidebar just stays empty and you conclude the fix doesn't work.

So the rule is: check both paths, and the live one is whichever already holds local_*.json files. If you want the package folder name for your own machine rather than trusting mine:

Get-AppxPackage -Name *Claude* | Select-Object PackageFamilyName

Two more things from @Orffyrus-Qc's tool that are worth knowing even if you do this by hand:

• Write the JSON as UTF-8 without BOM. PowerShell's Set-Content -Encoding utf8 adds a BOM, and the app's JSON parser skips the file without complaining. Another silent failure.
• Drive-letter changes break these entries too. The cwd is stored as an absolute path, so a project folder that moved from E: to F: leaves a registry row pointing nowhere.

Their tool handles all of this with a UI: https://github.com/Orffyrus-Qc/claude-session-repair

Sorry for the incomplete version. It was right for my machine, and I didn't know the install history mattered until someone with a different one tried it.

Thanks again @OBebel for taking the time to dig into this and refine the tool.
Your correction found a real case it got wrong, and everything you added made it better.

Fixed in v1.9.0:

• Both locations are checked now — the normal %APPDATA%\Claude path and the MSIX

package one — and whichever actually holds the local_*.json files is the one it uses.

• Your "same storage, two windows onto it" note turned out to matter more than expected.

On my machine both paths return the identical file ID, so the tool was listing the same
folder twice as if it were a choice between two registries. It now compares the real
directory identity instead of the path text, and shows them merged as one entry.

• It warns before writing to a location that looks dead. If the one you pick has no

sessions in it while another one does, it tells you first. That's exactly the silent
failure you described — nothing errors, the sidebar just stays empty, and you conclude
the fix doesn't work.

• It takes its own backup before the first change, so there's always something to go back to.

https://github.com/Orffyrus-Qc/claude-session-repair/releases/latest

Don't hesitate to send more feedback — this thread is the only reason the tool handles any
of these cases at all. Thanks to everyone who contributed.