[BUG] Auto-update DELETES sessiondata.vhdx — all Cowork projects, tasks and conversations destroyed (data loss, 2nd incident in 4 days, forensic evidence)

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 Claude Desktop auto-update flow DESTROYS all Cowork user data (projects, tasks, conversation history). This is my second data-loss incident in 4 days — see #65936 for the first one.

On June 10, 2026 (~08:33 local time) I clicked the in-app update card. The app restarted, applied the update to v1.11847.5.0 and forced a re-login. After logging back in, ALL Cowork projects and tasks were gone. I executed zero commands — no cleanup, no deletion, nothing. Only Chat history survived (server-side).

Forensic investigation confirmed the root cause: the updater deleted and recreated the user data disk.

Evidence:

1. vm_bundles\claudevm.bundle\sessiondata.vhdx (ext4, volume label "sessions" — the Cowork user data disk) has NTFS CreationTime = 10/06/2026 08:33:57 — created DURING the update. The previous file was deleted, not preserved.
2. Mounted the new VHDX read-only via WSL: dumpe2fs reports "Filesystem created: Wed Jun 10 08:34:41 2026", with 655,349 of 655,360 inodes free — a freshly formatted filesystem containing only OS provisioning data.
3. String-carving the block device found no trace of user content. Local LevelDB/IndexedDB stores contain no project metadata either.
4. On SSDs, NTFS TRIM makes the deleted VHDX unrecoverable within minutes. The data loss is silent and permanent.

Root cause hypothesis: the bundle provisioning step (download_and_sdk_prepare — see #65817, which identifies the smol-bin.x64.vhdx copy step) regenerates the ENTIRE vm bundle, including sessiondata.vhdx, instead of treating the sessions disk as persistent user data.

Suggested fix: the updater must never delete/recreate sessiondata.vhdx. At minimum, rename the existing one (sessiondata.bak.vhdx) before provisioning and surface a recovery prompt in the app.

Related: #65936 (my original report, same machine), #65817 (bundle provisioning failure point).

What Should Happen?

Accepting an app update must preserve all user data. Cowork projects, tasks and conversations should survive updates and re-logins intact.

Error Messages/Logs

NTFS file metadata (PowerShell Get-Item) on sessiondata.vhdx after the update:
CreationTime        LastWriteTime
------------        -------------
10/06/2026 08:33:57 10/06/2026 08:35:38

dumpe2fs -h on the new disk (mounted read-only via WSL):
Filesystem created:       Wed Jun 10 08:34:41 2026
Inode count:              655360
Free inodes:              655349
Mount count:              3

lsblk -f:
sde  ext4   1.0   sessions 2a9df914-ccfb-4728-8b70-98e530074426

The "sessions" disk is empty (only lost+found) — freshly formatted during the update.

Steps to Reproduce

1. Use Cowork normally (create projects and tasks)
2. Accept the in-app update prompt ("click to restart and update")
3. App restarts, applies update, forces re-login
4. Open Cowork: all projects and tasks are gone; sessiondata.vhdx has been recreated from scratch (check NTFS CreationTime)

Occurred on updates to v1.11187.4.0 (June 6) and v1.11847.5.0 (June 10). 100% data loss both times.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.11187.1.0

Claude Code Version

v1.11847.5.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment: Windows 11 Pro, Claude Desktop 1.11847.5.0 (AppX Claude_pzs8sxrjxfjjc), SSD storage, update accepted ~08:33 local time on June 10, 2026.

Full forensic outputs (Get-Item CreationTime, dumpe2fs header, lsblk, robocopy backup log) available on request — happy to provide logs or run additional diagnostics to help reproduce.