[BUG] Cowork destroys user files when reorganizing iCloud-offloaded documents (cp + rm -rf on 0-byte stubs)

[sweetrb]

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

1. On a Mac with iCloud Drive enabled and "Optimize Mac Storage" turned on
2. Have files in ~/Documents that have been offloaded to iCloud (local files are 0-byte stubs)
3. Select ~/Documents (or the user's home folder) as the Cowork workspace
4. Ask Cowork to reorganize files from one folder structure to another
5. Cowork runs cp -a source/ destination/ inside the Linux VM
6. 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 -rf on user data folders as part of a reorganization — mv is safer and more appropriate

Actual Behavior

1. cp -a silently copied 0-byte stubs, creating 0-byte files in the destination
2. Cowork did not check whether the copied files had any actual content
3. Cowork ran rm -rf on the three original folders, destroying the only reference iCloud had to the files
4. iCloud sync propagated the deletion, removing the cloud copies
5. ~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)

1. Never delete source files after copy. If the user asks to "reorganize" or "move" files, use mv — not cp followed by rm. The mv command is atomic on the same filesystem and would fail rather than silently produce empty files.

2. Validate copy integrity before any destructive action. After any cp operation, 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.

3. 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)

4. Require explicit user confirmation before any rm -rf on 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.

5. 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.

6. 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

7. Detect macOS "Optimize Mac Storage" setting and display a persistent warning in the Cowork UI when working with iCloud-synced directories.

8. 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:

1. Open Finder and navigate to the folders in question
2. Select all files → right-click → "Download Now" to force iCloud to cache files locally
3. Wait for downloads to complete before starting the Cowork task
4. 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

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Cowork can list but not read files in macOS FileProvider paths (Google Drive, Microsoft OneDrive) #29914
2. Sandbox creates 0-byte stub files that pollute git status #32177
3. [BUG] Cowork: Google Drive for Desktop mirrored/streaming folder fails to mount with "file exists" error #24134

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

[sweetrb]

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.

[drandom3]

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.