[BUG] Cowork destroys user files when reorganizing iCloud-offloaded documents (cp + rm -rf on 0-byte stubs)
Severity: Critical / Data Loss
Platform: macOS with iCloud Drive, "Optimize Mac Storage" enabled
Product: Claude Cowork (Desktop App — Research Preview)
---
Summary
During a file reorganization task, Cowork copied ~110 files from three folders in ~/Documents to a new directory structure using cp -a. Because macOS iCloud Drive's "Optimize Mac Storage" was enabled, most of those files existed locally only as 0-byte placeholder stubs, with actual content stored in iCloud. The Linux VM could not read through the iCloud stubs, so cp -a silently produced 0-byte copies. Cowork then ran rm -rf on the original folders, which propagated through iCloud sync and permanently deleted the cloud-stored originals. The files were not recoverable from iCloud's "Recently Deleted" — only Time Machine backup prevented total data loss.
The affected files were highly sensitive legal documents including divorce proceedings, guardianship petitions, police reports with video evidence, and family legal records.
Steps to Reproduce
- On a Mac with iCloud Drive enabled and "Optimize Mac Storage" turned on
- Have files in ~/Documents that have been offloaded to iCloud (local files are 0-byte stubs)
- Select ~/Documents (or the user's home folder) as the Cowork workspace
- Ask Cowork to reorganize files from one folder structure to another
- Cowork runs
cp -a source/ destination/inside the Linux VM - Cowork runs
rm -rf source/to clean up originals
Expected Behavior
- Cowork should detect that files are 0-byte iCloud stubs before attempting to copy them
- Cowork should warn the user that files need to be downloaded locally before they can be manipulated
- Cowork should never delete source files after a copy operation without first verifying that the copies are valid (non-zero, matching expected sizes)
- Cowork should never run
rm -rfon user data folders as part of a reorganization —mvis safer and more appropriate
Actual Behavior
cp -asilently copied 0-byte stubs, creating 0-byte files in the destination- Cowork did not check whether the copied files had any actual content
- Cowork ran
rm -rfon the three original folders, destroying the only reference iCloud had to the files - iCloud sync propagated the deletion, removing the cloud copies
- ~110 files were effectively destroyed, with only 5 files (that happened to be cached locally) surviving intact
Root Cause
The Cowork Linux VM accesses the macOS filesystem via a mount. iCloud Drive's "Optimize Mac Storage" feature replaces local file content with 0-byte placeholder stubs while keeping the real data in iCloud. These stubs are transparent to native macOS apps (which trigger an automatic download on access), but the Linux VM sees only the 0-byte stub — it cannot trigger iCloud's download mechanism.
The cp -a command faithfully copied what it saw: 0-byte files. No error was raised because from the filesystem's perspective, the copy succeeded. The subsequent rm -rf then deleted the stub files, which macOS/iCloud interpreted as intentional deletion, removing the cloud copies as well.
Impact
- 110+ files destroyed across multiple folders containing sensitive personal and legal documents
- Affected file types included PDFs, scanned TIFFs, videos (MP4/M4V), images (JPEG/PNG), Apple Pages documents, spreadsheets, and web bookmarks
- The documents were critical and irreplaceable — the kind of files a user cannot simply re-download or recreate
- Files were not recoverable from iCloud Recently Deleted
- Recovery was only possible because the user had Time Machine backups on a separate Mac
- Without Time Machine, this would have been permanent, irrecoverable data loss
Recommended Fixes
Critical (must fix)
- Never delete source files after copy. If the user asks to "reorganize" or "move" files, use
mv— notcpfollowed byrm. Themvcommand is atomic on the same filesystem and would fail rather than silently produce empty files.
- Validate copy integrity before any destructive action. After any
cpoperation, compare source and destination file sizes at minimum. If any destination file is 0 bytes when the source is not (or vice versa), abort and alert the user.
- Detect iCloud stubs. Before operating on files in ~/Documents, ~/Desktop, or other iCloud-synced directories, check for the presence of 0-byte files that have extended attributes indicating iCloud offloading (e.g.,
com.apple.icloud.itemDownloadRequested). Warn the user to download files locally first.
Important (should fix)
- Require explicit user confirmation before any
rm -rfon user data. A reorganization task should never silently delete folders containing the user's documents. At minimum, show the user what will be deleted and ask for confirmation.
- Log all destructive operations. Maintain a session log of all file operations (especially deletions) so that recovery steps can be identified if something goes wrong.
- Add a "dry run" mode for file reorganization tasks. Show the user the planned operations (what will be copied/moved where, what will be deleted) and get approval before executing.
Nice to have
- Detect macOS "Optimize Mac Storage" setting and display a persistent warning in the Cowork UI when working with iCloud-synced directories.
- Create a backup/snapshot before bulk file operations — even a simple manifest of filenames and sizes would help with recovery.
Workaround
Before using Cowork for any file operations in iCloud-synced directories:
- Open Finder and navigate to the folders in question
- Select all files → right-click → "Download Now" to force iCloud to cache files locally
- Wait for downloads to complete before starting the Cowork task
- Ensure Time Machine or another backup solution is current
Environment
- macOS Sequoia 15.7.1 (24G231) arm64
- Mac mini (M1, 2020), 16 GB RAM
- iCloud Drive enabled with "Optimize Mac Storage" on
- Disk nearly full: 446.70 / 460.43 GiB (97%) — likely contributing to aggressive iCloud offloading
- Many of the affected files had not been accessed for months or years, making them prime candidates for iCloud offloading
- Claude Desktop App — Cowork mode (Research Preview)
- Cowork Linux VM accessing macOS filesystem via mount
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is a different issue. The three listed issues are related to reading (not copying), git, and mounting files. This is about Claude Cowork not recognizing that a stub is there and copying and then deleting the empty file instead of downloading it first or issuing a warning and stopping. This issue, unlike those listed is destructive and unrecoverable unless the user has an external backup such as TimeMachine.
I had this issue exact issue. Claude Cowork copied all my files as stubs only (0 bytes). Have been dealing with apple support for ~1 week. Someone will be paying for my file loss, if apple are unable to do a server-side restore. Probably 10+ years of files, legal documents, company registration documents, tax documents.
(MacBook + iCloud "Keep Downloaded" + worked last week, broke after update)
You had a working setup with an iCloud folder set to "Keep Downloaded" (always local)
It worked last week, broke after a recent Claude Desktop update.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Second reporter — confirmed reproduction on macOS Tahoe 26.5 with iCloud Drive
Environment:
---
Confirming this bug as a second reporter, with an additional observation that may be of interest to whoever triaged this as stale on April 1st.
The workaround documented in the original report — force-downloading files via Finder's "Download Now" before any Cowork file operation — does work. I have independently verified this and documented it as a mandatory pre-flight step in my own workflow.
However, I would gently note that "the user must manually materialize all iCloud stubs before every file operation" is a mitigation, not a fix, and describes a responsibility that no user should reasonably bear. The original reporter lost 110+ files of sensitive legal documents. I discovered this bug before it destroyed my files only because I happened to be researching the issue with Claude — which is to say, I got lucky. Most users will not be that lucky, and will not find this GitHub issue until after the damage is done.
The original report's recommended fixes are precise, technically sound, and not particularly complex to implement. Notably:
mvinstead ofcp+rm -rfThese are not architectural changes. They are safety checks. The gap between "open bug causing irreversible user data loss" and "closed bug with basic copy validation" should not require a second reporter three months later to reopen.
I am not currently a developer, though I spent twenty years as one — including as a software architect at Excite.com. I now use Cowork as a writer and systems thinker organizing a creative writing project. I discovered this bug not through independent research, but in the course of a Claude conversation in which I was actively designing a file audit workflow for my writing project. Claude identified the bug report, explained the root cause, and helped me document the workaround — all before I had touched a single file. In other words: Claude protected me from Cowork. I will leave the organizational irony of that sentence as an exercise for the reader.
If I can identify this issue and document a workaround in an afternoon with no network engineering background, the engineering effort to fix it properly is not the bottleneck here.
I note this has been closed as "not planned" — by an automated bot, on inactivity grounds, not by a human engineer making a considered product decision. A bot decided the silence meant resolution. Given that a related file deletion bug (#67188) was filed two weeks ago, the silence was not resolution. It was just silence.
I would observe that "not planned" is an entirely reasonable response to a feature request. I would gently observe that "not planned" is an entirely reasonable response to a feature request. It is a considerably harder position to defend when the bug in question silently destroys user files and propagates the deletion through cloud sync with no warning, no recovery path, and no indication that anything went wrong. The original reporter lost irreplaceable legal documents. I nearly lost a year of creative work. The delta between "not planned" and "fixed" appears to be a file size check before a destructive operation. I leave the prioritization calculus as an exercise for the team.
Data loss bugs do not age out.
---
Backblaze confirmed running before I discovered this issue. Not everyone will be that fortunate either.
[PROCESS] Automated stale/close bot is silently closing critical data-loss bugs without human review
Type: Process / Issue Triage
Severity: High — affects user trust and product safety
Related issues: #32637, #67188
---
Summary
The current automated stale-and-close workflow is closing critical data-loss bug reports based solely on inactivity, without human review. This conflates two fundamentally different categories of silence: features nobody wanted, and bugs nobody fixed. The consequences are not equivalent and should not be treated as such.
Demonstration
Issue #32637 — "Cowork destroys user files when reorganizing iCloud-offloaded documents" — was filed March 9, 2026 with a Severity: Critical / Data Loss designation. It was marked stale by the bot on April 1st and closed as "not planned" by the bot on May 23rd. No human engineer comment appears in the thread indicating a product decision was made.
Two weeks after closure, issue #67188 was filed describing another instance of Cowork permanently deleting user files. The original issue was closed. The underlying problem was not.
A user finding #67188 today has no connection to #32637 and no awareness that this failure mode has been documented, reproduced, and closed without resolution. The bot tidied. The bug persisted.
The Problem
Automated inactivity closure assumes that silence means resolution. In practice, silence on a data-loss bug often means:
None of these are resolution. All of them are indistinguishable from resolution under a purely time-based triage policy.
Proposed Fix
Exempt issues carrying the
data-losslabel from automated stale marking and closure. Require a human engineer to explicitly close anydata-lossissue with a documented reason — fixed, won't fix with rationale, or duplicate with reference.This is not a large ask. It is standard triage hygiene for a severity class that involves permanent, irrecoverable destruction of user data.
A bot that cannot distinguish between an unwanted feature request and a file destruction bug should not have the authority to close the latter.
The Structural Trap
This is not a niche configuration. iCloud Drive is the default and effectively mandatory cross-device file system for macOS users. It is not a quirky choice — it is the architecture Apple provides and the one that makes files visible across Mac, iPhone, and iPad simultaneously.
The alternative — storing files locally outside iCloud and mounting them via SMB for cross-device access — is blocked by macOS itself. iCloud-managed folders cannot be shared via SMB. Apple prevents it by design. This is not a workaround gap. It is a wall.
Which means the user has no viable path that avoids iCloud. Files must live in iCloud to be accessible across devices. Cowork destroys files that live in iCloud. The bug therefore does not affect an edge case — it affects the default, recommended, and in practical terms only available architecture for Mac users who own more than one Apple device.
Framing this as a user configuration issue would be incorrect. Cowork breaks in the environment Apple built and that Apple users live in.
Why This Matters
Users who encounter Cowork data loss bugs currently face:
This is not a paper trail. It is the absence of one. For a product in Research Preview handling user files, that absence carries real risk — to users and to Anthropic.
---
Filed by GrammaJoJo — second reporter on #32637, confirmed reproduction on macOS Tahoe 26.5. Twenty years in software architecture, currently a writer and Cowork user. My files survived. Not because of anything Cowork did.
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.