[BUG] [BUG] Windows MSIX repair wipes the entire session store — 97 of 100 conversations unreachable while transcripts 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?

A Windows MSIX auto-repair destroyed my entire session store. After the
reinstall, 97 of 100 conversations were unreachable through the UI, while every
transcript file remained untouched on disk.

The sidebar reports "Session not found on disk" for each of them. That message
is misleading: the data IS on disk. Only the index pointing at it was deleted.

Measured the day after the incident:

| Measurement | Result |
|---|---|
| Transcript files in ~/.claude/projects | 365 files, 635 MB, intact |
| Full conversations among them | 100 |
| Sessions known to AppData\Roaming\Claude\claude-code-sessions | 3 |
| Files in the session store older than the reinstall | 0 |
| Oldest file in the session store | 18:41:01, ~2 min after the 18:39:10 reinstall |

Every file in both claude-code-sessions and local-agent-mode-sessions is
timestamped just after the reinstall. Nothing predating it survived.

Root cause: the session store lives inside MSIX package state that Remove
deletes. Transcripts survived only because they live in ~/.claude/projects,
outside the package. The reinstall created an empty store, and every prior
conversation became unreachable while remaining fully present on disk.

What led up to it: the Browser pane crashed the app while loading an external
page behind a Cloudflare bot check. Windows then ran RepairPackageOperation,
which failed at the registration step because a Claude process was still alive
(0x80073D02), and escalated to removing the package entirely:

| Time | What happened |
|---|---|
| 18:34:10 | Repair starts, step 1 (load new MSIX) succeeds |
| 18:34:51 | Step 2 fails: 0x80073D02, "the following apps must be closed" |
| 18:37:18 | Fallback: Reset -> Remove. Package moved to WindowsApps\Deleted |
| 18:37:33 | Restore fails twice: manifest gone (0x80073CF0), package not in repository (0x80073CF1) |
| 18:39:10 | Manual reinstall from %TEMP%\Claude-<id>.msix |
| 18:41:01 | Session store recreated, empty |

Ruled out: no memory shortage (31 GB RAM, 15.6 GB free), no Windows system
crash, no WER entry, no crash event logged for claude.exe.

What Should Happen?

User conversation history must not live inside removable package state.

Either store the session index next to the transcripts in ~/.claude, or rebuild
it from the transcripts at startup when entries are missing. Everything needed
for that rebuild is already sitting on disk, untouched.

Additionally:

• A destructive repair should warn that local app data will be lost, before

doing it.

• Windows/App-Installer repair should not proceed to a Remove fallback while the

target process is still detected as running. It should wait, prompt, or
terminate cleanly first.

Error Messages/Logs

Windows AppXDeployment-Server, RepairPackageOperation on the Claude MSIX package:

18:34:10  Repair started. Step 1 (load new MSIX): success
18:34:51  Step 2 failed: 0x80073D02
          "installation not possible, the following apps must be closed"
          (a Claude process was still alive at this point)
18:37:18  Fallback triggered: Reset -> Remove
          Package folder moved to C:\Program Files\WindowsApps\Deleted
18:37:33  Restore attempt 1 failed: 0x80073CF0  (manifest gone)
18:37:33  Restore attempt 2 failed: 0x80073CF1  (package no longer in repository)
18:39:10  Manual reinstall from %TEMP%\Claude-<id>.msix
18:41:01  Session store recreated — empty

Second occurrence ~2h later, same pattern, failed already at step 1:
          0x80070002  (MSIX in %TEMP% had since been cleaned up)

Browser pane, immediately before the crash:
          RPC connection ended: EOF

CoworkVMService on start:
          failed to configure SCM recovery actions; if the service crashes it
          will not restart until the machine reboots: Access is denied.

Not present in any log: no WER crash-report entry, no crash event for
claude.exe, no Windows system crash, no out-of-memory condition
(31 GB RAM, 15.6 GB free, pagefile peak 1.3 GB).

Session store state, measured the following day:
          AppData\Roaming\Claude\claude-code-sessions
          - files older than the 18:39:10 reinstall:  0
          - oldest file:  18:41:01
          ~/.claude/projects
          - transcript files:  365  (635 MB, all intact)
          - full conversations:  100
          - of those reachable in the UI:  3

Steps to Reproduce

1. Install Claude Desktop on Windows 11 as an MSIX package
2. Use the in-app Browser pane to load an external page behind a bot check;

the app crashes

1. Run "Repair" in Windows App settings while a Claude process is still alive
2. Repair fails with 0x80073D02 and escalates to removing the package
3. Reinstall the app
4. Observe: the entire session history is gone from the sidebar, while

~/.claude/projects/**/*.jsonl is untouched

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.113

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Relation to existing issues

The end symptom matches #63082, #63839, #61608, #61952 and #63801.

The root cause here is different from #63082 (startup scanner stripping
cliSessionId). Several distinct paths appear to lead to the same
unreachable-history state, which suggests the underlying problem is structural:
conversation history is not protected against loss, there is no export function,
and there is no rebuild from the transcript files that are sitting right there.

#63082 was closed as "not planned". Given that a second, independent path to the
same data-loss outcome exists, I would ask that it be reopened.

Contributing factors found in logs

1. CoworkVMService cannot register recovery actions on start: "failed to

configure SCM recovery actions; if the service crashes it will not restart
until the machine reboots: Access is denied." The service does not return on
its own after a crash.

1. Two parallel claude-code CLI installs on PATH (npm-global 2.1.63, native

2.1.113). The native one wins; the npm-global copy is stale.

1. Disk at 96% full, tight for MSIX staging during repair, which is exactly the

step that failed.

Impact

This is a paid business account used for client work. Source code survived under
version control. What was lost is the record of why each decision was made,
which is what makes months-long work on the same systems viable and what is
needed to diagnose issues a client reports later.

Recovery required writing a custom script to parse the raw .jsonl files
directly, because the application offers no export path. Most users could not do
this, and none should have to.

Workaround

If the app becomes unresponsive, do NOT click Repair or Reset in Windows App
settings. Fully terminate all Claude-related processes (including
CoworkVMService), reboot Windows, then repair.

To recover conversations after the store has been wiped: transcripts remain in
~/.claude/projects/**/*.jsonl as plain JSONL and can be parsed directly.
claude --resume also still works against them from the CLI.