[BUG] Cowork: Finder drag-drop from workspace folder to Electron apps (WhatsApp, Slack) silently deletes source file — FUSE volume-ID triggers macOS move semantics

Bug: Drag-and-drop from Cowork workspace folder into third-party apps silently deletes the source file

Severity

Critical — silent data loss with no user-level workaround. No prompt, no warning, no trash recovery. The standard macOS user-level mitigation for unwanted moves (holding ⌥ during drag to force copy) was tested and does not prevent the deletion. Particularly severe because Cowork targets non-technical users who will not recognise the failure mode, will assume the file "just disappeared", and have no way to recover it.

This is the second known silent-data-loss mode in the Cowork FUSE mount subsystem on macOS. The first, [#32637](https://github.com/anthropics/claude-code/issues/32637) (Cowork destroys iCloud-offloaded files via cp + rm -rf on 0-byte stubs), is still OPEN, has a confirmed second reporter, and was marked stale on 2026-04-01 with no fix shipped. The Cowork workspace mount on macOS should be treated as a high-risk subsystem warranting a cross-cutting safety net (see mitigation #1) rather than per-symptom patches.

Summary

Dragging a file from the Cowork workspace folder (as mounted in macOS Finder) into a third-party Electron app such as WhatsApp Desktop moves the file instead of copying it. The original is removed from the workspace folder. The user sees the file attached in WhatsApp but the file is no longer anywhere on disk the user can reach.

Environment

• macOS (tested: recent version)
• Cowork desktop app, workspace folder mounted via FUSE
• Destination tested: WhatsApp Desktop (Electron). Likely reproduces with Slack, Mail, Telegram, and any other Electron app that accepts file drops.

Reproduction

1. Open the Cowork desktop app and select a workspace folder.
2. Have Claude create a file in that folder (e.g. a PDF, Word doc).
3. In macOS Finder, navigate to the workspace folder and confirm the file is present.
4. Drag the file from Finder directly into an open WhatsApp Desktop chat window and release.
5. Observe the file is attached in WhatsApp.
6. Return to Finder. The file is gone from the workspace folder. It is not in Trash.

Also tested — and does NOT prevent the deletion: holding ⌥ (Option) during the drag. On a normal macOS volume this forces copy semantics (NSDragOperationCopy), and the cursor shows the green + copy badge. On the Cowork workspace FUSE mount the original is still removed. This means the ⌥ modifier, the standard macOS user-level workaround for unwanted moves, is not a viable mitigation for this bug. Users have no way to fix this themselves without avoiding drag-drop entirely.

Expected behaviour

Drag-and-drop from a user-facing folder into a messaging app copies the file. The original remains on disk.

Actual behaviour

The file is moved. The original is deleted from the workspace folder. No warning, no Trash entry.

Suspected root cause

This is deeper than Finder's copy-vs-move heuristic. The fact that holding ⌥ (which sets NSDragOperationCopy and normally guarantees the source is preserved) does not save the file proves that the deletion is not happening at the Finder drag-operation layer. Finder is being told "copy", the cursor shows the copy badge, and the file is deleted anyway.

Most likely, the deletion is occurring inside the FUSE mount layer's handling of the drag-out file promise. When the receiving app (WhatsApp / Electron) fulfils the file promise and reads the file, the FUSE mount's implementation unlinks the source as part of the drop completion — regardless of whether Finder negotiated a copy or a move operation. In other words, the FUSE layer is treating every drag-out as a move.

Contributing factors may include:

• Volume-ID reporting. FUSE mounts frequently do not report a stable fsid / volume identifier, which breaks several macOS heuristics that distinguish same-volume from cross-volume operations at the VFS level.
• File promise fulfilment. If the mount layer implements NSFilePromiseProvider or equivalent, the copy-vs-move decision may be hard-coded or driven by the wrong signal.
• Electron / Chromium drop handling. Electron apps typically move files into their own sandboxed storage on drop. On a correctly-behaved volume this is a copy at the filesystem level; on the Cowork FUSE mount it collapses into a move regardless of what the drag operation said.

Whatever the exact chain, the upshot is the same: the ⌥-drag workaround does not work, and there is no user-level mitigation for this bug. It must be fixed in the Cowork mount layer or worked around inside the Cowork desktop app.

This is reproducible across any Electron-based file drop target, not WhatsApp specifically.

Impact

• Data loss with zero warning. Any work Claude has produced and saved to the workspace folder can be destroyed by a routine "send this to a friend" action.
• Non-technical users cannot diagnose this. The failure mode looks like the file "just vanished" and will generate support tickets that read "Claude deleted my CV".
• Common, natural user flow. Sharing generated docs with colleagues/friends via a chat app is one of the most obvious things a Cowork user will do.

Suggested mitigations (in order of effort)

Note that because the ⌥-drag workaround does not work, there is no viable user-level mitigation. Any fix has to live inside the Cowork desktop app or its FUSE mount layer. Documentation alone is not enough — users will still lose files.

1. Versioned trash / undo — strongly recommended as a cross-cutting safety net, and the highest-priority fix. On any file unlink inside the workspace mount, retain the file in a local .cowork-trash/ (or rsync-style .cowork-history/ with size and mtime) for N days. This is the only mitigation that covers both this bug and [#32637](https://github.com/anthropics/claude-code/issues/32637) — and any future data-loss mode in the same subsystem that hasn't been discovered yet. Given #32637 has been open and unfixed for over a month, and given that the ⌥-drag workaround for this bug does not work, a generic safety net is clearly a better use of engineering time than per-symptom fixes. Cheap to ship, enormous blast-radius reduction.
2. Fix the FUSE mount's handling of drag-out / file promises so that a drag operation requesting copy semantics actually performs a copy and leaves the source intact. This is the real root-cause fix, and the only one that restores correct drag-drop behaviour.
3. Intercept drag-out from the workspace mount at the app level and force a true copy-to-tempdir-then-hand-off. If the FUSE fix is non-trivial, the Cowork desktop app can watch for drag sessions originating from the workspace folder and materialise the file into a native-volume temp directory before the drop completes, handing that path to the receiving app instead of a FUSE-mount path. Avoids fighting Electron apps over semantics.
4. Block or warn on drag-out until a fix ships. Interim: on any drag session whose source is the workspace folder, either (a) refuse the drag with a tooltip ("Dragging files out of the Cowork workspace folder is temporarily disabled due to a data-loss bug — use the attach button in your destination app instead"), or (b) show a blocking confirmation dialog on drop. Ugly, but guarantees no more silent loss while a proper fix is developed.
5. Documentation and onboarding notice. Add a warning to Cowork onboarding, the workspace folder setup screen, and the help center article [Get started with Claude Cowork](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork), clearly stating that drag-out from the workspace folder can delete the original file and should be avoided. Not a fix, but stops the bleeding for users who read docs. Do not include the ⌥-drag workaround in this notice — it does not work and will give users false confidence.

Workaround for users today

Do not drag files out of the Cowork workspace folder at all. There is no safe way to do it.

• Holding ⌥ (Option) while dragging does not work — tested, the original is still deleted even with the copy cursor showing.
• Use the destination app's attach button (📎 / paperclip / "Attach file") and browse to the file. This path always performs a proper read and leaves the source intact.
• Or copy the file to Desktop, Downloads, or another native (non-FUSE) location first using cp in Terminal or a normal Finder copy, then drag from there.
• If possible, keep a second copy of anything important outside the Cowork workspace folder until this is fixed.

Related issues

• [#32637](https://github.com/anthropics/claude-code/issues/32637) — Cowork destroys user files when reorganizing iCloud-offloaded documents (cp + rm -rf on 0-byte stubs). Status: OPEN, stale as of 2026-04-01, confirmed by a second reporter, no fix shipped. Different root cause (Cowork Linux VM running destructive shell commands on iCloud stubs vs. macOS Finder's volume-ID heuristic defaulting to move), but same subsystem and same failure class — silent data loss from the Cowork workspace mount on macOS. The existence of two independent data-loss modes in the same subsystem, one of which has been unresolved for over a month, is itself a signal that the subsystem needs a cross-cutting safety net.
• [#40973](https://github.com/anthropics/claude-code/issues/40973) — FUSE mount of selected folder does not expose pre-existing files (Windows, non-home-dir path). Different symptom, but also a FUSE-mount correctness bug.
• [#42520](https://github.com/anthropics/claude-code/issues/42520) — Cowork FUSE mount cache coherency failure on host-side file writes. Sandbox sees corrupted file content with null-byte padding when files shrink, or hard truncation when files grow. Also a FUSE-mount correctness bug.

Together these suggest the Cowork FUSE mount layer on macOS (and by extension the equivalent layer on Windows) is a high-risk area that has been accumulating correctness and data-loss bugs without a unified mitigation strategy.