Desktop app Code tab does not list CLI sessions from ~/.claude/projects

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?

The Code tab sidebar in Claude Desktop only lists sessions that were started from within the app. Sessions created by the claude CLI and stored in ~/.claude/projects/ are never shown, even when the app's folder selector points at the exact working directory those sessions were archived under.

There is no indication anywhere in the UI that two separate session stores exist. The empty state reads "Sessions you start will appear here", which a user reasonably reads as "you have no history" rather than "this panel does not show CLI history".

This is not cosmetic. After a failed MSIX update I had to reinstall Claude Desktop. On first launch the Code tab sidebar was empty while the dashboard on the same screen reported 175 sessions / 44,542 messages / 45.6M tokens. My reasonable conclusion was that the reinstall had destroyed my history. It had not — 79 .jsonl transcripts were intact on disk the whole time — but I only established that by inspecting the filesystem manually with PowerShell. A less technical user would have concluded their work was gone.

The app reads the selected directory correctly: it detects the git branch, current commit, uncommitted changes, and CLAUDE.md contents. It simply does not read ~/.claude/projects.

What Should Happen?

The sidebar should list the CLI sessions archived under the selected working directory, visually distinguished from app-created sessions if the distinction matters internally.

Failing that, the UI should state plainly that the panel lists app sessions only, and point to claude --resume for terminal history.

Possible fixes, in rough order of effort:

Minimum: change the empty-state copy so it does not imply the absence of history.
Better: read ~/.claude/projects/<encoded-cwd>/ for the selected folder and list those transcripts alongside app sessions.
Best: a single unified session store, so the CLI and the desktop app become two views of the same history rather than two disjoint sets.

Error Messages/Logs

No error is produced. The failure is silent — the sidebar renders its empty state as if no history existed.

For reference, the transcripts are present and readable on disk:

PS> Get-ChildItem "$env:USERPROFILE\.claude\projects" -Recurse -Filter *.jsonl |
      Measure-Object | Select-Object Count

Count
-----
   79

And claude --resume lists them correctly from the terminal, so the data is both present and correctly indexed by the CLI.

Steps to Reproduce

No error is produced. The failure is silent — the sidebar renders its empty state as if no history existed.

For reference, the transcripts are present and readable on disk:

PS> Get-ChildItem "$env:USERPROFILE\.claude\projects" -Recurse -Filter *.jsonl |
Measure-Object | Select-Object Count

Count
-----
79

And claude --resume lists them correctly from the terminal, so the data is both present and correctly indexed by the CLI.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

N/A — see above.

Claude Code Version

2.1.226

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

The transcripts are keyed solely by the working directory the process was launched from, encoded into a folder name. There is no project metadata inside the .jsonl — the first line contains only type, operation, timestamp, sessionId and content.

This is presumably why the two stores never meet: the app has no lookup path into the CLI's directory-encoded archive. A lightweight index mapping projects to sessions would make history discoverable regardless of which client wrote it, and the information needed to build it is already available at each Read/Edit call.

Filing this separately from the MSIX install failure (HRESULT 0x80073CF6) that led me to reinstall, which appears to be already reported.