[BUG] Cowork on Windows does not support UNC paths or mapped network drives as workspace folders
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Cowork mode on Windows cannot reliably use a UNC path (\\server\share\...) or a mapped network drive (Z:\ from net use Z: \\server\share) as a workspace folder. Selecting such a path produces inconsistent, partially-broken behavior across Cowork's three internal layers — the desktop client, the file tools (Read/Write/Edit), and the sandboxed Linux shell that backs the document-processing skills. The same paths work without issue in Claude Code (the CLI), so this is a Cowork-specific architectural gap rather than a Claude limitation.
This blocks enterprise users whose primary file storage is a corporate Windows file server, including most mid-sized law firms, accounting practices, healthcare administrators, and government offices.
What Should Happen?
UNC paths and mapped network drives behave like local folders for all Cowork operations — directory listings, file reads/writes, and skill execution — matching how Claude Code handles them.
Error Messages/Logs
# Layer 1: Desktop client / mount
Sometimes the UNC path is accepted as a workspace folder, sometimes it is rejected outright with no clear reason. Behavior is inconsistent across sessions.
# Layer 2: File tools (Read / Write / Edit)
Partial and unpredictable access. Reads on individual sub-paths sometimes succeed; reads on the workspace root return:
Read on `\\<server>\<share>\<folder>` is blocked in this session — it resolves to a protected location or a path outside the connected folder.
Directory listings frequently come back empty even when the share contains many files. This produces the classic "some folders work, others don't" symptom.
# Layer 3: Sandboxed Linux shell (the backing for all document-processing skills)
This layer is a hard, categorical block. **Every shell command — including a plain `ls` — fails immediately with:**
UNC paths are not supported: \\<server>\<share>\<folder>
This is the most damaging failure because every Cowork skill that does real document work (PDF rasterization, openpyxl, python-docx, timeline extraction, demand-letter drafting, complaint drafting) shells out to Python through this sandbox. If the sandbox can't traverse the path, none of those skills can operate on files in the workspace folder, regardless of what the file tools manage to do.
Steps to Reproduce
N/A
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
not sure
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
_No response_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗