[BUG] Cowork: Minor version update permanently deletes chat history and scheduled tasks

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/35131
2. https://github.com/anthropics/claude-code/issues/29373
3. https://github.com/anthropics/claude-code/issues/29154

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I also have this issue. Claude Cowork in Claude PRo in windows 11 Pro. Today after a version update a prior project -- which was my only project -- was completely deleted. I lost two days of work on that project which had exceeded available memory on both days. Claude had a lot of trouble with reorganizing documents in a folder which is supposed to be a straightforward, core task for the model. The prior project was nowhere to be found and Clauide reported that it found no session or project history at all.

Requesting to keep this open — this is not a duplicate of the flagged issues.

Why this is distinct from the flagged duplicates

All three flagged issues (#35131, #29373, #29154) describe a different failure mode:

| | Flagged duplicates | This issue (#38055) |
|---|---|---|
| Platform | macOS (all three) | Windows 11 Pro |
| Data on disk? | Files preserved, just not displayed | Files permanently gone — no recovery possible |
| Root cause | Index/directory migration missing | New VM UUID provisioned on update; previous UUID directory wiped |
| Chat history | Recoverable via manual file copy | Unrecoverable (not a display bug) |
| Scope | Primarily Code sessions | Cowork chat history + scheduled tasks (sessiondata.vhdx) |

On Windows, Cowork chat history is stored inside the VM's sessiondata.vhdx. When the update provisions a new VM UUID, the entire previous VM state — including sessiondata.vhdx — is discarded. No claude-code-sessions/ migration folder is created (unlike macOS in #35131). The data cannot be recovered from disk because it was never written to a user-accessible location.

As confirmed by @Shiney1965 above, this affects multiple Windows users independently.

Note on remediation overhead

Even "recovering" from this bug required significant manual investigation: checking filesystem paths, cross-referencing multiple internal documents, searching existing GitHub issues for workarounds, and reconstructing scheduled task definitions from separately-stored backup files. This is non-trivial remediation effort for what should be a zero-data-loss upgrade path.

The minimum viable fix would be a pre-update warning dialog: _"This update will reset your Cowork VM. Your chat history and scheduled tasks will be permanently lost."_ A proper fix would migrate sessiondata.vhdx content and session files between VM UUID directories on update, consistent with what macOS already attempts (even if imperfectly).

As a comment on remediation -- I don't think that a deletion warning would be very helpful (although of course it is better than nothing). In my case the update was necessary because CoWork stopped working due to the VM failure to activate error. Installing the new version fixed that error, but erased the chat history and projects. The purpose of "projects" is to keep a work file open over multiple days because many Cowork tasks require multiple days of work given its memory budget. I have not used "Skills" training but I understand its purpose is also to help Cowork remember how to do something that it had to learn how to do the first time. So any erasure of the session/project/skill data seems to defeat the essential purpose of the features and Cowork itself, which is intended to function over multiple sessions without reinventing the wheel (and wasting tokens) each session.

Thank you @Shiney1965 for sharing your experience and for the thoughtful remediation feedback!

Your description matches what I reported — complete data loss after a version update on Windows 11, with no session or project history recoverable. It's helpful to have another confirmed case to strengthen the report.

And you're absolutely right that a deletion warning alone isn't sufficient. The whole purpose of Cowork's session/project/skill system is to enable continuity across multiple sessions without re-learning or wasting tokens each time. An update that silently wipes all of this state is a critical regression — the fix should ensure data is preserved across updates, not just warn users before deleting it.

Did y'all try rebooting? That fixes it on macOS

Thanks for the suggestion! On macOS, rebooting may restore the session display — but on Windows the failure mode is different: the entire sessiondata.vhdx (containing chat history and scheduled tasks) is permanently deleted when a new VM UUID is provisioned during update. There's nothing left to recover after a reboot, as the data was never written to a user-accessible path. A proper fix would need to preserve or migrate the VM state across updates, not just restart.

That's right same here. I can confirm reboot does not help on windows 11 Pro.

Thank you @Shiney1965 for the additional confirmation! This is consistent with what I've observed — on Windows, the session data folder is completely deleted during the update process, so rebooting cannot restore it. Hopefully this gets addressed in an upcoming fix.

I woke up to the same issue this morning. My Claude restarted, made me log in again and deleted all my cowork and code history. Code history not a problem as they are all saved and i use terminal most of the time anyway. Cowork history - big problem - only scheduled tasks could be recovered. I have some cowork conversations that were not converted to skills or scheduled tasks so they are gone.

Also, my Dispatch history was moved to Code and cannot be seen in Cowork, or on my phone. Cowork is asking to reestablish Dispatch.

I tried rebooting MacOS but to no avail. (running MacOS Sonoma 14.6.1 (23G93)

After a lengthy conversation with Claude Chat, it confirmed my Cowork history was gone and sent me here to log it, which is how i found this post.

Thanks for sharing your experience, @wkejunk. Really sorry to hear this happened to you as well — losing Cowork conversations that hadn't been saved as skills or scheduled tasks is especially frustrating.

The Dispatch history being moved to Code and becoming inaccessible in Cowork sounds like an additional regression on top of the core history deletion issue. Good to know it also affects macOS Sonoma.

Hopefully having more reports helps Anthropic prioritize a fix. Appreciate you taking the time to document it here.

Happened to me as well, reboot didn't work either.
I just lost a lot of work..... sigh

Sorry to hear this happened to you as well — losing work to a routine update is genuinely frustrating. You're not alone; there are now multiple confirmed reports across both Windows and macOS. Hopefully the growing number of cases helps Anthropic prioritize a fix.

Update, I restarted again today and everything is back!

good for you @mattjaker . I tried restarting again to see if it fixed mine but it did not. And now my dispatch history which was in Code is now gone too.

From now on everything in cowork becomes a scheduled task before i got to bed at night.

Glad to hear it came back, @mattjaker! Thanks for the follow-up update.

The fact that a second restart resolved it is an interesting data point — it suggests the history may not be permanently deleted in all cases, but could be temporarily inaccessible during the update's initial migration phase.

Note: This is an automated supplementary note based on direct experience with this system.

This intermittent recovery behavior is consistent with a race condition during the update rollout: if the session database is being relocated or renamed as part of the migration, the first post-update launch may encounter files in an intermediate state (partially moved, not yet committed). A subsequent restart allows the migration routine to fully complete, making the session files discoverable again. This also explains the divergence in outcomes between users — those whose previous Cowork instance was not fully shut down before the update applied may have in-memory session state that was never flushed to disk, making recovery impossible regardless of the number of restarts. The reproducibility of this difference would be a useful signal for the team to investigate.

Hoping for a fix. I just lost a lot of work.

Thank you for your comment! I appreciate you sharing your experience. Let's hope the maintainers can address this soon.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.