[BUG] [Cowork] Attaching a local file hard-links it into local-agent-mode-sessions, silently breaking Microsoft Word's Cmd+S

[KahootGenius]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Claude Desktop's local agent mode (Cowork) stages chat attachments by creating a hard link (link(2)) of the user's original file under:

~/Library/Application Support/Claude/local-agent-mode-sessions/<workspace-uuid>/<session-uuid>/local_<uuid>/uploads/

This raises the original file's link count from 1 to 2. Microsoft Word for Mac performs its normal save as an atomic replace (write temp file, swap in a new inode) and refuses to do this on any file whose link count is > 1: after attaching, Cmd+S and the toolbar Save button silently do nothing — no error, no dialog, no write. Occasionally Word instead shows "Word cannot complete the save due to a file permission error." Panel-mediated saves (Save As, the save-on-close prompt) take a different code path and still work, which masks the failure and prevents users from connecting it to Claude.

Net effect: any Word document a user attaches to a Cowork chat while still editing it loses normal saving in Word until they Save As or the extra link is removed.

Environment

• Claude Desktop 1.24012.9 (macOS), local agent mode / Cowork session (Claude Code 2.1.219)
• macOS 26.5.2 (build 25F84), APFS — attachment staging dir and original on the same volume
• Microsoft Word for Mac 16.111 (user's symptoms predate the 16.111 update, so not new in 16.111)

What Should Happen?

Attaching a file to a Cowork chat should not mutate the original file's filesystem state. Staging should use an APFS clone or copy so the original keeps link count 1 and saving in other apps is unaffected.

Error Messages/Logs

Usually none — the save fails silently. Occasionally: 'Word cannot complete the save due to a file permission error.' No sandbox denials or failing syscalls; Word bails out before any filesystem call.

Steps to Reproduce

Steps to reproduce

1. Create test.docx on the Desktop and open it in Word (local file, AutoSave off). Confirm Cmd+S works: stat -f 'links=%l inode=%i mtime=%Sm' ~/Desktop/test.docx — mtime advances and the inode changes on each save; link count is 1.
2. In Claude Desktop, start a local agent (Cowork) session and attach test.docx to the chat.
3. Re-run the stat: link count is now 2, and the same inode appears under .../local-agent-mode-sessions/.../uploads/test.docx.
4. Type a character in Word and press Cmd+S.

Actual: nothing is written — mtime and size unchanged, Word's title bar drops the "— Saved to my Mac" suffix, and the document keeps its unsaved-changes state. Usually there is no error at all; occasionally Word shows the "file permission error" dialog. Expected: the file saves.

Isolation (Claude removed from the loop)

The mechanism is purely the link count — reproducible without Claude Desktop:

ln ~/Desktop/test.docx /tmp/extra-link.docx   # Cmd+S in Word now silently fails
rm /tmp/extra-link.docx                       # Cmd+S works again immediately

Link count > 1 is necessary and sufficient. Word bails out before making any filesystem call (no failing syscall, no sandbox denial in unified logging), so nothing in the OS points back at the cause. A successful Save As writes a new inode at the original path, which detaches the file from the staged link and "fixes" it — until the next attach.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.219

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Impact

• Silent data-path failure in the most common editor workflow (Cmd+S), triggered minutes to hours earlier by an unrelated-looking action in a different app.
• The only user-visible breadcrumb is a ~15-year-old generic Word error message whose public troubleshooting advice (fix permissions, grant Full Disk Access, reset containers, reinstall Office) sends users on a long goose chase.
• Word is unlikely to be unique: any app that refuses multi-link targets during safe-save behaves the same way.

Two distinct problems with link(2) staging

1. Apps that refuse multi-link files (Word's safe save): saving breaks as described above.
2. Apps that write in place (many CLI tools, some editors): they mutate the shared inode, so the staged "upload" changes after attach — the session's attachment snapshot is not immutable, and the agent may later read content the user never attached.

Suggested fix

Stage attachments with APFS clones instead of hard links: clonefile(2), or copyfile(3) with COPYFILE_CLONE, falling back to a plain copy on non-APFS/cross-volume paths. A clone has the same disk-space benefit as a hard link but is a distinct inode: the original keeps link count 1 (Word unaffected), and the staged file is a true immutable snapshot (fixes both problems).

Workaround for affected users

After attaching a doc you're still editing, either do one Save As over the same name, or replace the staged hard links with real copies:

find "$HOME/Library/Application Support/Claude/local-agent-mode-sessions" -type f -links +1 \
  -exec sh -c 'cp -p "$1" "$1.t" && mv -f "$1.t" "$1"' _ {} \;