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

Resolved 💬 1 comment Opened Apr 16, 2026 by caseyi Closed May 24, 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?

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.
  1. 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."
  1. 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."
  1. 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.
  1. 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.
  1. 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_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗