[BUG] [BUG] Cowork session data stored under a temp dir inside vm_bundles; VM corruption = total history loss. Is there any server-side copy?

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 23, 2026

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 recovering from the install failure described in my other issue (orphaned
CoworkVMService → 0x80073CF6 → clean reinstall), all my Cowork session history was
gone — the Cowork UI shows an empty list. Forensic inspection of the old data
directory shows the session data lived inside a VM disk image stored in a temporary
directory, which was corrupted during the original failure. One crash therefore
destroyed the entire Cowork history.

What I found (old data dir preserved before reinstall)

Old desktop data dir (%LOCALAPPDATA%\Claude-3p, backed up before reinstall):

  • The .vhdx is corrupted / truncated: 7-Zip reports unexpected end of data,

Convert-VHD fails with 0x80070570 (file or directory is corrupted).

  • SHA-256 of the first 100 MB of the corrupted .vhdx is identical to the image

freshly decompressed from rootfs.vhdx.zst → the corrupted file is a truncated
copy of the pristine template, and the template itself contains no user data
(/home/ubuntu is empty, no .claude/projects).

  • local-agent-mode-sessions in the old data dir contains only 13 files / 84 KB —

a single session's metadata, not the dozens of sessions I ran.

  • Host-side ~/.claude/projects only contains CLI sessions (which are fine), not

Cowork sessions.

Conclusion: Cowork session transcripts existed only inside runtime VM state under a
.wvm-tmp-* directory, and were lost when that state was corrupted.

Questions / requests

  1. Is any Cowork session history retained server-side? The fresh install's

Cowork UI does render a (now single-entry) session list, which suggests some
server-side indexing. If transcripts or metadata exist server-side, an option to
restore them to a reinstalled client would rescue users in my situation.

  1. Please move durable session data out of temp directories. Storing the only

copy of user session history inside .wvm-tmp-* runtime state means any crash
or interrupted migration silently destroys it.

  1. Please add an export/import or re-index mechanism so that a reinstall (which

the 0x80073CF6 bug currently forces) does not orphan existing local session data.

Environment

  • OS: Windows (x64)
  • Claude Desktop: MSIX Claude_1.20186.1.0_x64__pzs8sxrjxfjjc
  • Related issue: [link to Issue 1 after posting it]

What Should Happen?

Cowork session history should survive a crash or reinstall. Durable session data should not have its only copy inside a temporary VM state directory (.wvm-tmp-*), where one interrupted operation destroys all history. There should be a server-side copy restorable to a reinstalled client, and/or an export/import or re-index mechanism for local session data.

Error Messages/Logs

Steps to Reproduce

Summary

After recovering from the install failure described in my other issue (orphaned
CoworkVMService → 0x80073CF6 → clean reinstall), all my Cowork session history was
gone — the Cowork UI shows an empty list. Forensic inspection of the old data
directory shows the session data lived inside a VM disk image stored in a temporary
directory, which was corrupted during the original failure. One crash therefore
destroyed the entire Cowork history.

What I found (old data dir preserved before reinstall)

Old desktop data dir (%LOCALAPPDATA%\Claude-3p, backed up before reinstall):

  • The .vhdx is corrupted / truncated: 7-Zip reports unexpected end of data,

Convert-VHD fails with 0x80070570 (file or directory is corrupted).

  • SHA-256 of the first 100 MB of the corrupted .vhdx is identical to the image

freshly decompressed from rootfs.vhdx.zst → the corrupted file is a truncated
copy of the pristine template, and the template itself contains no user data
(/home/ubuntu is empty, no .claude/projects).

  • local-agent-mode-sessions in the old data dir contains only 13 files / 84 KB —

a single session's metadata, not the dozens of sessions I ran.

  • Host-side ~/.claude/projects only contains CLI sessions (which are fine), not

Cowork sessions.

Conclusion: Cowork session transcripts existed only inside runtime VM state under a
.wvm-tmp-* directory, and were lost when that state was corrupted.

Questions / requests

  1. Is any Cowork session history retained server-side? The fresh install's

Cowork UI does render a (now single-entry) session list, which suggests some
server-side indexing. If transcripts or metadata exist server-side, an option to
restore them to a reinstalled client would rescue users in my situation.

  1. Please move durable session data out of temp directories. Storing the only

copy of user session history inside .wvm-tmp-* runtime state means any crash
or interrupted migration silently destroys it.

  1. Please add an export/import or re-index mechanism so that a reinstall (which

the 0x80073CF6 bug currently forces) does not orphan existing local session data.

Environment

  • OS: Windows (x64)
  • Claude Desktop: MSIX Claude_1.20186.1.0_x64__pzs8sxrjxfjjc
  • Related issue: [link to Issue 1 after posting it]

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.20186.1.0 (Claude Desktop MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗