claude-code - 💡(How to fix) Fix [BUG] Cowork session transcripts and outputs are not durable, and the UX strongly implies they are — weeks of professional work lost [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49498Fetched 2026-04-17 08:39:26
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
1
Author
Participants
Timeline (top)
labeled ×5cross-referenced ×1subscribed ×1

Cowork presents as if it is working on the user's computer — filesystem access, a "working directory" concept, references to local files — but session transcripts and outputs are stored in ephemeral per-session VM-mounted directories under ~/Library/Application Support/Claude/local-agent-mode-sessions/<org>/<user>/local_<session-id>/ that can be wiped by:

  • A corrupted VM bundle triggering cleanup
  • Standard troubleshooting steps (including ones suggested by Claude itself and by community guides) that recommend rm -rf on the sessions directory
  • Reinstalling or resetting the desktop app
  • Any scenario where the VM state is rebuilt

Session transcripts are not synced to claude.ai server-side the way regular chat transcripts are. They do not appear in the web sidebar. Unless the user explicitly copies outputs to their host filesystem or uses the Filesystem MCP with an authorized host directory, everything lives only inside the per-session VM mount.

As a result, a user can run Cowork sessions for weeks or months, accumulate substantial work product (code, documents, research, analysis, planning), experience a VM crash or follow troubleshooting guidance, and lose all of it with no warning and no recovery path.

Error Message

After the April 2026 auto-update, Cowork sessions crashed with Claude Code process exited with code 1 / Failed to create bridge sockets after 5 attempts (matching open issues #40540, #39270, #46029, #47104). Standard troubleshooting — cache clear of local-agent-mode-sessions/, claude-code-vm/, vm_bundles/ — is widely suggested for this error class. Following those steps destroyed weeks of Cowork work including in-progress product specs, design iteration history, and analysis artifacts that directly feed country deployments. 5. Troubleshooting guidance is destructive. When Cowork fails (which it has been doing frequently since March 2026 per the open issue tracker), the standard fix involves deleting exactly the directory that contains all the user's history. The app does not warn that these directories contain unrecoverable user data.

Error Messages/Logs

Root Cause

Cowork presents as if it is working on the user's computer — filesystem access, a "working directory" concept, references to local files — but session transcripts and outputs are stored in ephemeral per-session VM-mounted directories under ~/Library/Application Support/Claude/local-agent-mode-sessions/<org>/<user>/local_<session-id>/ that can be wiped by:

  • A corrupted VM bundle triggering cleanup
  • Standard troubleshooting steps (including ones suggested by Claude itself and by community guides) that recommend rm -rf on the sessions directory
  • Reinstalling or resetting the desktop app
  • Any scenario where the VM state is rebuilt

Session transcripts are not synced to claude.ai server-side the way regular chat transcripts are. They do not appear in the web sidebar. Unless the user explicitly copies outputs to their host filesystem or uses the Filesystem MCP with an authorized host directory, everything lives only inside the per-session VM mount.

As a result, a user can run Cowork sessions for weeks or months, accumulate substantial work product (code, documents, research, analysis, planning), experience a VM crash or follow troubleshooting guidance, and lose all of it with no warning and no recovery path.

Fix Action

Fix / Workaround

it was during an upgrade to the latest

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Title: Cowork session transcripts and outputs are not durable, and the UX strongly implies they are — weeks of professional work lost

Summary

Cowork presents as if it is working on the user's computer — filesystem access, a "working directory" concept, references to local files — but session transcripts and outputs are stored in ephemeral per-session VM-mounted directories under ~/Library/Application Support/Claude/local-agent-mode-sessions/<org>/<user>/local_<session-id>/ that can be wiped by:

  • A corrupted VM bundle triggering cleanup
  • Standard troubleshooting steps (including ones suggested by Claude itself and by community guides) that recommend rm -rf on the sessions directory
  • Reinstalling or resetting the desktop app
  • Any scenario where the VM state is rebuilt

Session transcripts are not synced to claude.ai server-side the way regular chat transcripts are. They do not appear in the web sidebar. Unless the user explicitly copies outputs to their host filesystem or uses the Filesystem MCP with an authorized host directory, everything lives only inside the per-session VM mount.

As a result, a user can run Cowork sessions for weeks or months, accumulate substantial work product (code, documents, research, analysis, planning), experience a VM crash or follow troubleshooting guidance, and lose all of it with no warning and no recovery path.

What happened in my case

I am a Director of Product at UW Digital Initiatives Group (DIGI) working on OpenELIS Global, an international open-source laboratory information management system deployed across clinical laboratories in low- and middle-income country health systems. I use Cowork extensively for OpenELIS product and engineering work: redesigned feature specs, FRS documents, architecture analysis, analyzer integration adapter specs, and high-priority items tied to immediate country-level needs (ministries of health, NGOs, clinical deployments).

After the April 2026 auto-update, Cowork sessions crashed with Claude Code process exited with code 1 / Failed to create bridge sockets after 5 attempts (matching open issues #40540, #39270, #46029, #47104). Standard troubleshooting — cache clear of local-agent-mode-sessions/, claude-code-vm/, vm_bundles/ — is widely suggested for this error class. Following those steps destroyed weeks of Cowork work including in-progress product specs, design iteration history, and analysis artifacts that directly feed country deployments.

The transcripts were not on claude.ai. The IndexedDB and Local Storage caches total ~7 MB, not remotely enough to hold session content. The 13 GB of local Claude data was almost entirely the Linux VM rootfs and extension node_modules — essentially none of it was user content.

Why the UX makes this worse

  1. "Working directory" implies persistence. When Cowork prompts for a working directory at session start, a reasonable user assumes files created during the session will live in or relative to that directory. In practice, outputs go to an internal per-session mount unless the user explicitly invokes the Filesystem MCP or copies files out.

  2. No visible distinction between VM paths and host paths. Session logs show paths like /sessions/quirky-funny-newton/mnt/... and /home/bold-upbeat-keller which look like normal filesystem paths but are inside the ephemeral VM. There is no UI affordance that says "this file lives in the VM only."

  3. No sync indicator. Regular Claude chats show as synced to the cloud; Cowork sessions do not have an equivalent indicator that says "this conversation exists only on this machine and only until the VM state is reset."

  4. No export / backup affordance. There is no "export session" button, no "save transcript" option, no periodic autosave to a known host location, no warning before destructive VM operations.

  5. Troubleshooting guidance is destructive. When Cowork fails (which it has been doing frequently since March 2026 per the open issue tracker), the standard fix involves deleting exactly the directory that contains all the user's history. The app does not warn that these directories contain unrecoverable user data.

  6. Marketing vs reality mismatch. Features like "Control Cowork from your phone with a persistent thread" strongly imply server-side durability. Users reasonably assume Cowork conversations have the same persistence guarantees as regular chats.

Requested changes

  • Sync Cowork transcripts to claude.ai server-side the way regular chats are. This is the single change that would have prevented the loss.
  • Until that ships: persistent local storage in a clearly-labeled, user-visible host directory (e.g., ~/Documents/Claude Cowork/<session-name>/) with transcripts in markdown and outputs alongside them.
  • UI differentiation between VM-internal paths and host paths in Cowork's file displays.
  • Export/backup affordance on every session — at minimum "Save transcript as..." and "Copy outputs to..."
  • Warning dialog before destructive operations that would delete session data (VM reset, cache clear from within the app, app reinstall).
  • Update troubleshooting guidance to instruct users to back up local-agent-mode-sessions/ before any cache-clearing step.

Environment

  • macOS (Apple Silicon)
  • Claude Desktop (latest as of 2026-04-16)
  • Claude Code 2.1.111
  • Plan: Team
  • Org ID: a70feff3-23d4-4a71-8985-82ac0274d145

Related issues

  • #40540 (SDK flag incompatibility causing exit code 1)
  • #39270 (Claude Code process exited with code 1 on macOS after update)
  • #46029 (Cowork sessions crash after update)
  • #47104 (Cowork/Connectors/Claude Code broken after auto-update)

These are all upstream triggers that lead users to the data loss described here.

What Should Happen?

  • Sync Cowork transcripts to claude.ai server-side the way regular chats are. This is the single change that would have prevented the loss.
  • Until that ships: persistent local storage in a clearly-labeled, user-visible host directory (e.g., ~/Documents/Claude Cowork/<session-name>/) with transcripts in markdown and outputs alongside them.
  • UI differentiation between VM-internal paths and host paths in Cowork's file displays.
  • Export/backup affordance on every session — at minimum "Save transcript as..." and "Copy outputs to..."
  • Warning dialog before destructive operations that would delete session data (VM reset, cache clear from within the app, app reinstall).
  • Update troubleshooting guidance to instruct users to back up local-agent-mode-sessions/ before any cache-clearing step.

Error Messages/Logs

Steps to Reproduce

This is just an example of a systemic issue, this will happen to tons of users who will lose everything before they know what happened due to a bad update.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

it was during an upgrade to the latest

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

extent analysis

TL;DR

To prevent data loss in Cowork sessions, the most likely fix is to implement a mechanism for syncing Cowork transcripts to the claude.ai server-side, similar to regular chats, or provide a persistent local storage solution with clear user warnings before destructive operations.

Guidance

  • Implement server-side syncing: Modify the Cowork application to sync session transcripts to the claude.ai server, ensuring data persistence and recovery.
  • Provide local storage fallback: Until server-side syncing is available, offer a local storage solution in a user-visible directory (e.g., ~/Documents/Claude Cowork/<session-name>/) with transcripts and outputs.
  • Differentiate VM and host paths: Update the UI to clearly distinguish between VM-internal paths and host paths in file displays.
  • Add export and backup options: Introduce "Save transcript as..." and "Copy outputs to..." features for each session, allowing users to manually backup their work.
  • Update troubleshooting guidance: Revise troubleshooting steps to instruct users to backup local-agent-mode-sessions/ before performing any cache-clearing operations.

Example

No specific code example is provided due to the nature of the issue, but implementing a syncing mechanism could involve modifying the application's data storage and retrieval logic to interact with the claude.ai server.

Notes

The solution requires careful consideration of user data privacy and security, especially when implementing server-side syncing. Additionally, the local storage fallback should be designed to minimize data loss in case of application or system failures.

Recommendation

Apply a workaround by providing a persistent local storage solution and updating the UI to differentiate between VM and host paths, while working towards implementing server-side syncing as a long-term solution. This approach balances immediate user needs with the necessity of a more robust, server-side solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Cowork session transcripts and outputs are not durable, and the UX strongly implies they are — weeks of professional work lost [1 participants]