[CRITICAL BUG] Cowork Mode Sandbox Overlay Silently Deletes All Existing Files in Mounted Directories

[CRITICAL BUG] Cowork Mode Sandbox Overlay Silently Deletes All Existing Files in Mounted Directories

Environment

• Claude Desktop: 1.3109.0
• macOS: Tahoe 26.3.1 (25D2128)
• Feature: Cowork Mode (Research Preview)
• Intercom Conversation ID: 215473981920839

Summary

When a Cowork mode session writes new files to a user-mounted directory, the sandbox overlay filesystem replaces the entire directory contents instead of merging writes with existing files. All original files in the mounted directory are permanently deleted — not moved to Trash, not recoverable without external backup.

Reproduction Steps

1. Open Cowork mode in Claude Desktop 1.3109.0 on macOS Tahoe 26.3.1
2. Mount a folder from ~/Documents that contains existing files (e.g., .docx, .xlsx, .png, .pdf files across subdirectories). In my case, I mounted multiple folders under a project directory including subdirectories for specific workstreams.
3. In the Cowork session, ask Claude to create new files in the mounted folder. Claude uses the Write tool (for file creation on the host filesystem) and/or bash with python-docx (for .docx generation in the sandbox, then synced back) to generate new .docx files in the same directories that contain existing user files.
4. During the session, Claude's Glob tool and bash ls inside the sandbox can no longer see the original files — only the newly created files appear. However, Claude's Read tool falsely reports that the original files still exist (returning "binary file" errors for .docx/.xlsx, which normally indicates the file is present). This discrepancy between tools makes diagnosis extremely difficult.
5. After the session ends (or during, if checked via macOS Finder or Terminal), ALL original files in every mounted directory are gone. Only the newly written files remain.
6. Originals are not in macOS Trash.
7. macOS Terminal ls -la on the host confirms the deletions:

user@Mac ~ % ls -la ~/Documents/ProjectFolder/Subfolder/
total 16
drwxr-xr-x  4 user  staff   128 Apr 19 10:39 .
drwxr-xr-x  7 user  staff   224 Apr 19 09:57 ..
-rw-r--r--@ 1 user  staff  6148 Apr 19 10:39 .DS_Store
drwxr-xr-x  4 user  staff   128 Apr 18 22:13 Legal

This directory previously contained folders of screenshots, an .xlsx message log, demand letters, and analysis documents — all gone, replaced by only the two .docx files Claude created inside Legal/.

What Claude Did (Exact Tool Usage)

During the Cowork session, Claude performed the following operations that triggered the bug:

1. Read existing files — Claude used Read tool and bash (with python-docx/openpyxl) to read the contents of existing .docx and .xlsx files in the mounted directories. This worked correctly.

1. Created new .docx files via bash — Claude ran Python scripts in the sandbox using python-docx to generate new Word documents. These were written to sandbox mount paths like /sessions/[session-id]/mnt/[folder-name]/subfolder/NewFile.docx, which map to the user's real filesystem at ~/Documents/ProjectFolder/Subfolder/NewFile.docx.

1. Also used the Write tool — Claude used the Write file tool to create markdown (.md) source files and then generated .docx files from them. The Write tool writes directly to the host filesystem paths.

1. Wrote to multiple mounted directories — New files were written to 4 different mounted subdirectories over the course of the session. In each directory, Claude created 1-3 new .docx files alongside dozens of existing files of various types.

1. Result — In every directory where Claude wrote a new file, ALL pre-existing files were deleted. The directories were left containing only Claude's newly created files plus .DS_Store.

Root Cause

The sandbox overlay filesystem creates a layer on top of the user's real directories. When new files are written to the overlay, the overlay layer replaces the underlying directory contents upon sync-back to the host filesystem, rather than merging with existing files. It appears that the overlay treats the directory as "this is the complete state" rather than "these are the changes to merge."

Compounding diagnostic issue: Claude's own Read tool falsely reports that original files still exist (it appears to hit a cached/snapshot layer), while Glob, bash ls, macOS Finder, and macOS Terminal ls all confirm the files are deleted. When the user reported missing files, Claude initially insisted the files were still there based on Read tool results, delaying discovery of the actual data loss. The user had to run ls in their own macOS Terminal to confirm ground truth.

Specifically, Claude ran these checks and got contradictory results:

• Read tool on ~/Documents/ProjectFolder/Subfolder/OriginalFile.docx → returned "This tool cannot read binary files" (meaning file exists, it's just binary)
• Glob tool with pattern **/* on the same directory → did not list the original file, only showed new files
• bash ls in sandbox on /sessions/.../mnt/folder/ → did not list the original file
• User's macOS Terminal ls -la → did not list the original file

Claude told the user "Every single original file still exists on your filesystem" based on the Read results. This was wrong.

Files Deleted

The following types of files were permanently deleted from 4 mounted subdirectories:

Directory 1 (case workstream A):

• Folders of timestamped screenshots (evidence for active legal cases)
• .xlsx spreadsheet with message logs and damages calculations
• .docx demand letter already sent to opposing party
• .docx comprehensive case analysis document
• .md drafting instructions

Directory 2 (case workstream B):

• .docx discovery strategy document
• .docx demand letter with detailed segment analysis
• .docx earlier demand letter

Directory 3 (shared legal background):

• .docx circuit split analysis
• .docx litigation playbook
• .docx case law compilation
• .docx filing checklist
• .docx 810KB research transcripts
• .docx demand letter template

Directory 4 (regulatory documents):

• Two .pdf government registration confirmation documents

Some files were partially recovered from iCloud backup, but local and iCloud copies had diverged due to edits made in a prior Claude session (which also went through the sandbox overlay), so recovery was incomplete.

These are irreplaceable files for active legal cases being filed this week.

Additional Issues Found During This Incident

1. /bug command does not work in Cowork mode

The Fin AI Agent support bot (Intercom conversation ID: 215473981920839) repeatedly suggested typing /bug in the desktop app to file a bug report. The bot then clarified that /bug is only available in Claude Code, not in Cowork mode. This means:

• Cowork mode has no built-in bug reporting mechanism
• The support bot gives incorrect guidance to Cowork users
• The only paths are GitHub issues or HackerOne, neither of which the support bot can submit on behalf of the user

2. No destructive action warning

The user had explicitly configured preferences requiring permission before destructive actions. The sandbox overlay deletion bypasses this entirely because it happens at the filesystem level, not through any tool that Claude controls or can gate with a confirmation prompt. There is no warning, no confirmation dialog, no undo.

3. Support bot cannot escalate to humans

When asked to escalate to a human engineer, the Fin AI Agent responded: "I can't directly escalate this conversation to a human engineer from here." For a critical data-loss bug, there is no path from the support widget to human support — only redirects to GitHub/HackerOne.

4. Misleading tool diagnostics delay discovery

As described above, Claude's Read tool reports files exist while Glob and bash do not see them. Claude initially told the user "your files are NOT deleted" and "Read tool confirms they still exist on your real filesystem" — this was wrong. The Read tool was hitting a snapshot/cache layer, not the real filesystem. This caused the user additional distress and delayed the actual recovery effort (checking iCloud, Time Machine).

Intercom Support Transcript Summary

Conversation ID: 215473981920839
Date: April 19, 2026

The full bug report was filed via the Intercom support widget on support.claude.com (accessed from claude.ai > Get Help). The conversation included:

1. Initial report — Full description of the bug including product, date, severity, what happened (5-step narrative), all affected directories, root cause analysis identifying the sandbox overlay, and request to escalate to engineering.
2. Bot response — Asked for app version, macOS version, reproduction steps, Console.app logs, and screenshots. Suggested /bug or GitHub issues.
3. Follow-up with reproduction steps — Provided structured 5-step reproduction, additional context about the nature of deleted files (evidence for active legal cases filing this week), partial iCloud recovery, and repeated escalation request.
4. Bot response — Acknowledged the writeup, repeated the same two options (GitHub issues, HackerOne). Could not escalate to a human.
5. User reported /bug doesn't work — Bot confirmed /bug is Claude Code only, not available in Cowork mode.
6. Request for human escalation — Bot confirmed it cannot directly escalate to a human engineer.

Expected Behavior

Writing new files to a mounted directory should merge with existing directory contents, not replace them. At minimum:

• The sandbox should preserve all files that existed before the session started
• If overlay replacement is somehow architecturally necessary, the user must be warned before the session begins that existing files in mounted directories may be affected
• Existing files should be backed up or moved to Trash, not silently deleted
• Claude's Read and Glob tools should report consistent filesystem state — not one tool saying files exist while another says they don't
• Cowork mode should have a /bug command or equivalent built-in bug reporting mechanism
• The support bot should be able to escalate critical data-loss reports to human engineers

Severity

Critical — silent, permanent, unrecoverable data loss with no warning, no confirmation, no undo, misleading diagnostic output from Claude's own tools, and no effective path to human support during the incident.