Detailed Analysis
A user-submitted bug report on the r/ClaudeAI subreddit details a reproducible and potentially serious file-corruption issue affecting the macOS Claude Desktop app, specifically within its Cowork mode. The report documents that uploading a .docx file to Claude—whether via drag-and-drop or the standard file-attach button—renders the original file on disk unsavable in Microsoft Word afterward, with Word throwing a "file permission error" on any subsequent save attempt. Critically, this occurs even when the file was never opened in Word during the upload process and even after the Claude Desktop app has been fully closed, meaning the damage is done silently at the moment of upload and persists independently of the app's runtime state.
The reporter's diagnostic work is notably rigorous, using ls -l@ to inspect the file's extended attributes and hard-link count before and after upload. The evidence shows the hard link count jumping from 1 to 2 and two new macOS sandboxing attributes appearing (com.apple.macl and com.apple.provenance), which are typically added when a sandboxed application is granted access to a specific file through an Open/Save panel (Apple's "Powerbox" mechanism). The reporter's working hypothesis, partly informed by Claude's own explanation of the issue, is that Word's Quick Look thumbnail-generation extension is being invoked to render a file preview during the upload/file-picker interaction, and this extension separately requests sandbox access to the file. That access grant then appears to conflict with Word's own save routine when the full application later tries to write to the same file path. Notably, PDFs uploaded the same way show no such problem, which is consistent with the theory since PDFs rely on macOS's built-in Quick Look renderer rather than a third-party Microsoft-authored extension.
This matters because it represents a case where an AI assistant's file-handling integration with the host operating system produces destructive side effects entirely outside the AI model's own behavior or judgment—this isn't a hallucination or a bad edit, but a low-level OS/sandbox interaction bug triggered simply by the act of referencing a file. For professionals who work from live, actively-edited documents—legal drafting, contract markup, litigation files, or any workflow where a working .docx is the single source of truth—this creates a nontrivial risk: uploading a document for Claude's assistance could silently break the ability to save further edits in Word, discovered only later and potentially without an obvious cause. The reporter's practical workaround (always uploading a disposable duplicate rather than the working file, or converting to PDF when only read access is needed) is a reasonable mitigation but places the burden on users to anticipate a non-obvious failure mode.
More broadly, this bug illustrates a recurring class of risk as AI coding and productivity tools like Claude's Cowork mode move from pure chat interfaces into deeper filesystem and application integration on desktop operating systems. As these tools gain the ability to read, reference, and manipulate local files directly—competing functionally with agentic coding tools and desktop copilots—they inherit the complexity of macOS's sandboxing, entitlements, and third-party OS extensions (like Quick Look plugins from Word, Excel, and other productivity suites), any of which can introduce edge-case conflicts. As AI assistants increasingly operate as first-class citizens on users' local machines rather than isolated cloud services, this kind of interaction bug—file permission corruption stemming from opaque OS-level sandbox bookkeeping—will likely become a more prominent category of trust and reliability concern, distinct from the model-quality issues that have dominated earlier discourse about AI assistant safety.
Read original article →