[BUG] Windows Store (MSIX) build: all local Claude Code sessions vanish from the Cowork sidebar after 1.49585 -> 1.52386 update; session files remain intact on disk

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?

Summary

After the desktop app auto-updated from 1.49585.0 to 1.52386.0, every local
Claude Code session disappeared from the Cowork sidebar. The sidebar shows an
empty list. No data was actually deleted: all 13 session records are still on
disk, in the correct account/org directory, with isArchived: false.

The app is the Microsoft Store (MSIX) packaged build, so its data lives under
the package-redirected path, not under %APPDATA%\Claude.

Environment

• OS: Windows 11 (win32 x64)
• Claude desktop: 1.52386.0 (previously 1.49585.0)
• Package: Claude_pzs8sxrjxfjjc (Microsoft Store / MSIX)
• Electron 44.2.0, Node 24.20.0
• Claude Code CLI: 2.1.266 (previously 2.1.258 / 2.1.260)
• Data root: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\

Timeline

• 2026-09-11 09:55 (UTC+8) — app auto-updated 1.49585.0 -> 1.52386.0.

Same run: CCD installed 2.1.266 and logged Removing old version: 2.1.258.

• 2026-09-12 12:54 — app restarted; sidebar session list is empty.

Evidence that the data is intact

1. Session records present. 13 files in

...\LocalCache\Roaming\Claude\claude-code-sessions\<account-id>\<org-id>\,
named local_*.json, 4.7-7.9 KB each, mtimes spanning 2026-08-18 to
2026-09-11. Every one has isArchived: false and a valid title, cwd,
cliSessionId, completedTurns.

1. Correct identity. The <account-id> and <org-id> directory names match

the account and org IDs in main.log for every startup from 2026-08-21
onward. There is no second/stale UUID directory, and no account switch —
only one orgId appears across the entire log history.

1. Transcripts intact. main.log on 2026-09-12 12:54:23 logs:

[CCD] Session 1d2f7f67-9104-4bca-9065-d180a18bc698 transcript is 54296720
bytes; tail-loading last 52428800 bytes — i.e. the app successfully read a
54 MB transcript on the same startup where the sidebar rendered nothing.

1. IndexedDB is healthy. IndexedDB\https_claude.ai_0.indexeddb.leveldb\000027.log

is 934,775 bytes and was being written the same day.

1. No errors in the log. %LOCALAPPDATA%\Claude\Logs\main.log contains no

database corruption, migration failure, or storage write error. The only
recurring error is unrelated:
[Chrome Extension MCP] Failed to copy native host binary: EBUSY.

What I tried (both failed, documented so others don't repeat them)

• Renamed IndexedDB to IndexedDB.bak and restarted. Sidebar still empty,

and no new IndexedDB directory was created.

• Copied the 13 session files into a swapped-order path

claude-code-sessions\<org-id>\<account-id>\ and restarted. No change.

Possible lead

The app's own directory layout is inconsistent about nesting order:

claude-code-sessions<account-id><org-id>\ <- sessions live here local-agent-mode-sessions\skills-plugin<org-id><account-id>\ <- reversed

I don't know which one the session enumerator expects after the update, but the
inconsistency seemed worth flagging.

Impact

The sidebar is the only entry point to local sessions in the UI, so when
enumeration fails the sessions are unreachable even though the files are sitting
right there. There is no in-product recovery path, no warning, and no indication
that anything is wrong — the list simply renders empty, which reads as "your
work is gone".

Recovering access required manually locating the MSIX-redirected data directory,
parsing the session JSON by hand, and falling back to claude --resume from a
terminal. That is not a reasonable recovery path for a data-loss-looking failure,
and it consumed a large amount of plan usage to recover data that was never lost.

What Should Happen?

If session metadata files exist and are valid, the sidebar should enumerate them.
If enumeration fails, the app should surface an error rather than silently
rendering an empty list — and there should be a documented way to re-index.

Error Messages/Logs

Steps to Reproduce

I cannot reproduce the trigger on demand — it was a one-time state
transition caused by an auto-update. The resulting broken state, however,
reproduces 100% of the time on this machine.

What produced it

1. Microsoft Store (MSIX) build, version 1.49585.0, in normal use since

2026-08-16. 13 local Claude Code sessions accumulated across project folders
under C:\Workspace\, created between 2026-08-18 and 2026-09-11, all
listed and working normally in the Cowork sidebar.

1. 2026-09-11 09:55 (UTC+8) — the app auto-updated itself to 1.52386.0 while

running. In the same run, CCD installed Claude Code 2.1.266 and logged
Removing old version: 2.1.258.

1. 2026-09-12 12:54 — launched the app.
2. The Cowork sidebar rendered an empty session list.

Current broken state — reproduces on every launch

1. Launch Claude desktop 1.52386.0.
2. Observe the Cowork sidebar: no local sessions listed.
3. Open

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-sessions\<account-id>\<org-id>\
and observe 13 valid local_*.json files, every one with
isArchived: false.

1. Open %LOCALAPPDATA%\Claude\Logs\main.log and observe that the same

startup successfully read a 54 MB transcript
([CCD] Session 1d2f7f67-… transcript is 54296720 bytes; tail-loading …)
with no storage or database error anywhere in the file.

Every launch since 2026-09-12 has behaved identically.

Likely reproduction on your side

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

2.1.260 (bundled with Claude desktop 1.49585.0)

Claude Code Version

2.1.266 (installed and managed by the desktop app, not a standalone install)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_