[BUG] Cowork session data inaccessible after restoring vm_bundles\claudevm.bundle from Recycle Bin — no warning this folder holds irreplaceable session data

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 10, 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?

After Cowork's sandbox began failing with "RPC error -1: failed to mount ... Plan9
share ... not mounted", I cleared vm_bundles\claudevm.bundle via Windows File
Explorer (moved to Recycle Bin) as part of standard cache-clearing troubleshooting.
This folder is not documented anywhere as containing irreplaceable data, and its
name/location alongside other clearly-disposable cache folders gives no indication
it holds anything unrecoverable.

I later discovered this bundle contains sessiondata.vhdx, the actual persistent
storage for all Cowork task history. I restored claudevm.bundle from the Recycle
Bin, but Cowork's sidebar still shows no task history for two specific sessions.

What Should Happen?

Either: (1) Cowork should not lose session visibility when vm_bundles is cleared
and then restored intact from the Recycle Bin, since the underlying VHDX data
was never actually deleted; or (2) at minimum, this folder should be clearly
documented or structurally distinguished as containing irreplaceable session
data, so users don't clear it during routine mount-error troubleshooting.

Error Messages/Logs

RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/horac/AppData/
Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-
sessions/f2888ba8-d6cc-4b16-bf23-9ff48fcfe39d/0f05dc2a-9d09-413d-bedf-58b797d933a4/
local_330252d7-25ae-432b-8d97-c7add246eae5/uploads as uploads: source path ...
is under Plan9 share "c" which is not mounted

Steps to Reproduce

  1. Cowork sandbox fails to mount with the Plan9/virtiofs error above (root cause

of this specific failure still unclear — see related issues #61559, #62937)

  1. As troubleshooting, clear vm_bundles\claudevm.bundle from:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\
(via File Explorer, moved to Recycle Bin, not permanently deleted)

  1. Restore claudevm.bundle from the Recycle Bin (confirmed same creation

timestamp as original, size 9.87GB, contents intact per attrib check —
no read-only flags anywhere)

  1. Fully quit Claude Desktop, confirm CoworkVMService is running

(sc.exe query CoworkVMService shows STATE: RUNNING), relaunch

  1. Cowork sidebar shows 0 of 2 expected historical tasks

Note: mounted sessiondata.vhdx directly via WSL2 (read-only) to inspect
independently of the app — confirmed the VHDX itself is intact (ext4, 16 session
folders present, correct VM ID matching the original error). Extensive filename
and content search across all 16 sessions could not locate the actual conversation
transcripts for the 2 missing tasks — only empty external-connector mount points
and MCP diagnostic logs were found. Also checked the documented
local-agent-mode-sessions\<org-id>\<user-id>\.claude\projects\ path (per
third-party documentation of Cowork's transcript storage) — this folder does
not exist on this install, confirmed with hidden items shown via
Get-ChildItem -Force.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.49585.0

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Install type: Microsoft Store/MSIX (confirmed via package path
Claude_pzs8sxrjxfjjc)

Support history: Filed via Fin AI chat and email (support@anthropic.com) —
both returned generic responses without human escalation; one confirmed public
report (#55879) documents Fin explicitly refusing human escalation in writing
on a similar Cowork data-loss case.

Full diagnostic trail available on request, including: VM disk mount
verification via Mount-VHD/wsl --mount, attrib output confirming no file
permission issues, sc.exe service status checks, and directory listings of
all 16 session folders. Happy to provide screenshots or raw command output
for any of the above.

View original on GitHub ↗