[BUG] Cowork: Folder does not support UNC under Windows

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/41687
2. https://github.com/anthropics/claude-code/issues/41914

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

Thanks for passing along the issue @mrsilva

We're deploying Claude Code org-wide (89+ employees across 10 departments) using a shared network drive with cascading CLAUDE.md files (org → department → person). The entire architecture depends on Cowork being able to open folders on the shared drive.

This is hugely problematic for us as well.

Also, both Win11's subst and symlink are being resolved to the UNC path, so we nave no workable resolutions for the team.
Cowork simply cannot access the project folders.

Win10 SMB to local NAS: "UNC paths are not supported: \path"

Same issue for me, actually no workarroud.
Mapping the UNC doesn't fixe the issue, the map drive is automaticlay shown as UNC.

UNC can be defined or selected as folder in cowork, but not used.
Error msg: "UNC paths are not supported: \\servername\shared-folder"

+1 - same bug with WSL folders. Connecting \\wsl$\Debian\... or \\wsl.localhost\Debian\... aborts the bash sandbox at boot with UNC paths are not supported: \\.... Every call fails before any command runs. Only fix is disconnecting every UNC folder.

Same issue for me on Claude 1.3883.0 (93ff6c) 2026-04-21T17:24:01.000Z running on Windows 11 as host and WSL ubuntu 24.04 as client. This is a bummer because Codex App can actually access folders inside WSL no issue. I need Claude desktop dearly as it's cowork can work on multiple-folders at once on a single project. Please fix this team Claude.

+1 — hitting this exact error trying to mount \\wsl.localhost\Ubuntu\home\<user> from Cowork on Windows. My day-to-day workflow lives entirely inside WSL (uv, ruff, mypy, Django projects), so the only workaround right now is to copy files out to a Windows path and back, which defeats the purpose of using Cowork as an assistant on real project files.

A couple of things that would help, in rough priority:

1. At minimum, allow \\wsl.localhost\<distro>\... and \\wsl$\<distro>\... UNC paths to be mounted as a Cowork directory (even read-only as a first step).
2. Even better, detect WSL UNC paths and offer a "reopen in WSL" remote mode like #49933 describes, so the sandbox runs Linux tools against the real Linux filesystem instead of going through the SMB share.

Lots of devs on Windows use WSL as their primary dev environment — landing this would unblock that whole audience for Cowork.

New subscriber. The first thing I tried to do was connect to my Obsidian vault on local share. This is making me regret not choosing ChatGPT.

New subscriber. The first thing I tried to do was connect to my Obsidian vault on local share. This is making me regret not choosing ChatGPT.

You can still have it read and write to obsidian. I do that.

+1
Same here

Helpful bump. Mapped UNC (sshfs in this case, but with an already-authed mapped drive win11 -> linux) still fails here. Rather annoying..

I works with Google code CLI (by using a network drive mapped to the UNC path). Is it new?

This is for Claude Cowork (Windows)

+1

Another one for Claude Cowork (Windows)

Company wide issue, was working fine a few versions ago.

+1 — I need this for a QNAP TS-464 NAS. My use case is pointing Cowork at an SMB share (a media directory) that contains a large amount of large files, so copying everything to a local folder first isn't feasible. Please add support for UNC/SMB network paths (\\server\share) as Cowork workspace folders on Windows. Mapping the share to a drive letter doesn't help either — it gets resolved back to a UNC path and fails with "UNC paths are not supported".

FYI: I had to leave Claude and switch to Codex to make this work. It's
takes a little fiddling around but you can get it to work with OpenAI's
stuff.

On Tue, Jul 7, 2026, 5:33 PM hookmt @.***> wrote:

hookmt left a comment (anthropics/claude-code#45297) <https://github.com/anthropics/claude-code/issues/45297#issuecomment-4909233232> +1 — I need this for a QNAP TS-464 NAS. My use case is pointing Cowork at an SMB share (a media directory) that contains a large amount of large files, so copying everything to a local folder first isn't feasible. Please add support for UNC/SMB network paths (\server\share) as Cowork workspace folders on Windows. Mapping the share to a drive letter doesn't help either — it gets resolved back to a UNC path and fails with "UNC paths are not supported". — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/45297?email_source=notifications&email_token=AKMYTMXA2U5XXZOVRRA3HK35DVUBBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQHEZDGMZSGMZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4909233232>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKMYTMR5GXS2NO3R2OYIDIT5DVUBBAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMRSGU3TQOBQHAZKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AKMYTMRJB3OVORQS7LQIH3L5DVUBBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQHEZDGMZSGMZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AKMYTMXLZOXWAEME6MN73635DVUBBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQHEZDGMZSGMZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

For teams and enterprises we need users to be able to cowork in the same folder.

+1

WSL2 folders broke after tasks started running in the cloud — workaround: disable "Run new tasks in the cloud" (file tools only)

My workflow: my project folders and repos live inside WSL2 (Ubuntu-24.04) at ~/, and I connect them to Cowork tasks as \\wsl.localhost\Ubuntu-24.04\home\<user>\... folders. This worked — Cowork's file tools could list, read, and edit those folders directly.

After a recent update, that same setup broke. New tasks began running in the cloud, and there the connected WSL folders are unusable: every file operation fails with UNC paths are not allowed: \\wsl.localhost\..., and the session reports no folders connected at all, even though they show as connected in the UI. The folder picker also silently no-ops in some cases (clicking "Add folder" on certain paths just does nothing, with no error).

The workaround for me was Settings → Cowork → "Run new tasks in the cloud" → off. With tasks running on my computer, the WSL2 folders are reachable again via the file tools (list/read/write/edit).

Note this is only a partial restoration, though: even in on-computer mode, bash commands and terminal access don't work normally against those folders — only the file tools do. So anything shell-based (git operations, running scripts over the folder, document-processing skills that shell out) is still broken on WSL folders in both modes.

Suggestions: surface an error when a connected folder is unreachable in a cloud session instead of failing silently at connect time; document that WSL/UNC folders currently require on-computer mode; and ideally, WSL-aware folder support like the Code tab already has (https://code.claude.com/docs/en/desktop-wsl), so shell access works too.

Environment: Windows 11, WSL 2.7.11, Ubuntu-24.04 (WSL2), Claude for Windows 1.24012.11 (09114b).

Yeah this is pretty annoying. Had to create an entire MCP toolset to allow claude to write, read & edit in WSL folders. Been an issue for a while and on every computer I've used claude with.

Unfortunately, it's disappointing that Claude Cowork is becoming a useless app for business purposes in companies that use a network drive or Google Drive for Desktop on Windows systems.

Small additional data point on the July 7 comment ("Mapping the share to a drive letter doesn't help either — it gets resolved back to a UNC path"): that is not what I see. In my environment a mapped drive letter does work — but read-only.

Concretely, on a corporate Windows file server (SMB):

| Access path | Read | Write |
|---|---|---|
| UNC (\\server\share\...) as a connected folder | ❌ | ❌ |
| Mapped drive letter (<X>:\...) as a connected folder | ✅ | ❌ |

So the drive-letter mapping is not simply resolved back to UNC and rejected — the folder is accepted, listing and reading files works, and only write operations fail.

That read/write asymmetry looks like a distinct layer from the hard UNC rejection in this issue, and it is worth keeping in an open issue: it was previously reported in #41687 (write to mapped network drives fails while the folder picker accepts the path), which was closed as not planned. #54069 describes the layering well — client, file tools, and the sandboxed shell each behave differently — and was closed as a duplicate of this one, so this issue is effectively the surviving home for all of it.

Worth noting for prioritization: this blocks the case where the organization's primary storage is a Windows file server, which is the normal setup in corporate environments — documents never live on the local disk. The Claude Code CLI handles these paths fine; only Cowork does not.

Environment: Desktop app version: 1.49585.0

Still present on Windows 11 (Sep 2026), and the rejection has gone silent.

Confirming this is live in the current desktop build — Windows 11 Pro 26200, Cowork. The symptom has changed shape since the original report, in a way that makes it harder to recognise:

• Original report (Apr): folder accepted, then fails at use time with UNC paths are not supported: \\...
• #56636 (now closed/locked): rejected at add time, with a visible message ("Network UNC paths are not supported here")
• Current build: rejected at add time with no message at all. Clicking Add folder opens the native Windows dialog, the share browses and selects normally, the dialog accepts the selection and closes without error — and no folder has been added. The workspace list is simply unchanged.

The native dialog resolving and accepting the path means the discard happens downstream of selection. From the user's side it's indistinguishable from a misclick, which is why it took a while to realise the folder hadn't attached at all.

Separately, the folder search field filters already-known folders rather than resolving paths, so typing a UNC there returns "No matches" — correct on its own terms, but the combined effect is that no point in the flow ever says UNC is unsupported.

The drive-letter workaround has a non-obvious cost.

Mapping the share to a drive letter does still work for attaching the folder in the current build. But it isn't free: #63527 documents that on Windows, a workspace reached through a mapped drive letter loses its Claude Code session history — the writer and the lister disagree once realpath dereferences the mapping, so transcripts land under a slug the lister never computes. The resolution established there is to open the workspace by its UNC path.

That leaves Windows network-share users choosing between two halves of the same product:

• map a drive letter → Cowork attaches the folder, Claude Code loses session history
• use the UNC path → Claude Code keeps its history, Cowork won't attach the folder

No configuration satisfies both. Worth knowing when weighing this issue's priority: the obvious workaround trades one bug for another rather than avoiding them.

Minimum ask, short of full UNC support: restore the explicit rejection message. Silently discarding a selection the file dialog just accepted is the worst of the three behaviours above.

Haven't you figured it out yet, anthropic doesn't care. Our requests are ignored. Same at openai and github so far. The support requests go unanswered. Why haven't they focused efforts on actually making agents to deal with consumer complaints? For all their preaching, this failure seems to be the most obvious telling limitation of ai.

Sent from Proton Mail for Android.

-------- Original Message --------
On Wednesday, 09/16/26 at 08:22 BLCKBOX (CyberDynamic) @.***> wrote:

AdamDShort left a comment (anthropics/claude-code#45297) Still present on Windows 11 (Sep 2026), and the rejection has gone silent. Confirming this is live in the current desktop build — Windows 11 Pro 26200, Cowork. The symptom has changed shape since the original report, in a way that makes it harder to recognise: - Original report (Apr): folder accepted, then fails at use time with UNC paths are not supported: \\... - #56636 (now closed/locked): rejected at add time, with a visible message ("Network UNC paths are not supported here") - Current build: rejected at add time with no message at all. Clicking Add folder opens the native Windows dialog, the share browses and selects normally, the dialog accepts the selection and closes without error — and no folder has been added. The workspace list is simply unchanged. The native dialog resolving and accepting the path means the discard happens downstream of selection. From the user's side it's indistinguishable from a misclick, which is why it took a while to realise the folder hadn't attached at all. Separately, the folder search field filters already-known folders rather than resolving paths, so typing a UNC there returns "No matches" — correct on its own terms, but the combined effect is that no point in the flow ever says UNC is unsupported. The drive-letter workaround has a non-obvious cost. Mapping the share to a drive letter does still work for attaching the folder in the current build. But it isn't free: #63527 documents that on Windows, a workspace reached through a mapped drive letter loses its Claude Code session history — the writer and the lister disagree once realpath dereferences the mapping, so transcripts land under a slug the lister never computes. The resolution established there is to open the workspace by its UNC path. That leaves Windows network-share users choosing between two halves of the same product: - map a drive letter → Cowork attaches the folder, Claude Code loses session history - use the UNC path → Claude Code keeps its history, Cowork won't attach the folder No configuration satisfies both. Worth knowing when weighing this issue's priority: the obvious workaround trades one bug for another rather than avoiding them. Minimum ask, short of full UNC support: restore the explicit rejection message. Silently discarding a selection the file dialog just accepted is the worst of the three behaviours above. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: @.***>

Ok I think I figured it out... It depends on how you create the project on Windows. Bc there is multiple ways to create a project.

If you
-> Projects on the LEFT SIDE BAR (if you try to click "New" and create a project in the chat that is where it hiccups on network drives)
-> New projects
-> Use a folder
-> Choose a different folder
-> Select your folder, always allow
-> When you do this it will say the folder you selected and + 1
-> ask in the chat as quickly as possible "Can you read this folder?"
-> a tab pops up "Allow this Cowork Session to Access this folder?", there is a bug where your cursor disappears
-> tab to select "Don't ask again for this folder on this device" then hit the space bar to check the box
-> tab back to "Allow" and hit enter

if you dont do "Don't ask again for this folder on this device" correctly when you go to a new chat in that project the files won't show

I've narrowed the issue down to how projects are created for my clients

it's annoying because the user has to follow these steps exactly when creating projects or it will hiccup

I'll try to put a step by step on my website soon

Ok I think I figured it out... It depends on how you create the project on Windows. Bc there is multiple ways to create a project. If you -> Projects on the LEFT SIDE BAR (if you try to click "New" and create a project in the chat that is where it hiccups on network drives) -> New projects -> Use a folder -> Choose a different folder -> Select your folder, always allow -> When you do this it will say the folder you selected and + 1 -> ask in the chat as quickly as possible "Can you read this folder?" -> a tab pops up "Allow this Cowork Session to Access this folder?", there is a bug where your cursor disappears -> tab to select "Don't ask again for this folder on this device" then hit the space bar to check the box -> tab back to "Allow" and hit enter if you dont do "Don't ask again for this folder on this device" correctly when you go to a new chat in that project the files won't show I've narrowed the issue down to how projects are created for my clients it's annoying because the user has to follow these steps exactly when creating projects or it will hiccup I'll try to put a step by step on my website soon

@kjagsadvisors, tried this and it seems to have worked....for now. We will see what tomorrow brings when I open claude cowork again. Thank you for taking time to post your workaround!

@kjagsadvisors OMG. Thank you! And its session stable. I tried and searched for weeks...

• Last change from me was: changing the SMB path to all lower-case

> Ok I think I figured it out... It depends on how you create the project on Windows. Bc there is multiple ways to create a project. > If you -> Projects on the LEFT SIDE BAR (if you try to click "New" and create a project in the chat that is where it hiccups on network drives) -> New projects -> Use a folder -> Choose a different folder -> Select your folder, always allow -> When you do this it will say the folder you selected and + 1 -> ask in the chat as quickly as possible "Can you read this folder?" -> a tab pops up "Allow this Cowork Session to Access this folder?", there is a bug where your cursor disappears -> tab to select "Don't ask again for this folder on this device" then hit the space bar to check the box -> tab back to "Allow" and hit enter > if you dont do "Don't ask again for this folder on this device" correctly when you go to a new chat in that project the files won't show > I've narrowed the issue down to how projects are created for my clients > it's annoying because the user has to follow these steps exactly when creating projects or it will hiccup > I'll try to put a step by step on my website soon @kjagsadvisors, tried this and it seems to have worked....for now. We will see what tomorrow brings when I open claude cowork again. Thank you for taking time to post your workaround!

Seems to be the correct fix! Thank you!