Claude desktop auto-update reset Cowork VM workspace directory, wiping existing files
An in-place auto-update of the Claude desktop app (1.21459.0.0 → 1.21459.3.0) triggered a restart of its Cowork VM service. Within 2-4 minutes of that restart, my workspace directory D:\trading had its pre-existing contents (multiple scripts and directories) replaced with what looks like a freshly-provisioned scaffold — a partial venv (only pandas installed) and app config files (servers.dat, terminal.lic), with nothing else surviving.
Timeline (from Windows System/Application logs and C:\ProgramData\Claude\Logs\cowork-service.log):
- 10:44:28 AM — Cowork VM service session ended, cowork-svc.exe stopped; Windows Error Reporting logged claude.exe (1.21459.0.0) as hung at the same moment.
- 10:44:29 AM — Claude service start type changed as part of the update.
- 10:44:31–10:44:38 AM — App updated to 1.21459.3.0; Cowork VM service restarted, reinitializing HCS/Hyper-V compute and creating a fresh VM session.
- 10:46–10:48 AM — D:\trading\Config and D:\trading\venv written to disk; all prior scripts/directories gone.
Expected: An auto-update restarting the Cowork VM session should not modify or reset the contents of a user's existing workspace directory on the host filesystem.
Actual: The directory's contents were replaced. No Recycle Bin entry and no Volume Shadow Copy exist for recovery — file-system/process-creation auditing wasn't enabled on this machine, so this is a strong timing correlation rather than a definitive process-level trace, but no other activity in that window touched the directory.
Environment: Windows 11 Pro 10.0.26100, Claude app 1.21459.0.0 → 1.21459.3.0, working directory D:\trading.