[FEATURE] Cowork (Windows): allow connecting folders that live in WSL

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Re-filing #61003, which was auto-closed as stale and locked with no maintainer response. Still reproducible as of October 2026 (Claude Desktop 2.19675.0.0).

On Windows, Cowork can't attach any folder that lives inside a WSL distro. The folder is \\wsl.localhost\Ubuntu-24.04\home\<user>\dev. Retested today:

Rejected up front:

• A subfolder of that path (e.g. \\wsl.localhost\Ubuntu-24.04\home\<user>\dev\<project>), reached by browsing into a Quick Access pin to the dev folder: error dialog "Network (UNC) paths are not supported here."

<img width="352" height="125" alt="Image" src="https://github.com/user-attachments/assets/02557cff-8ece-480d-bbd3-7363091e6ac9" />

Accepted by the picker, then failed at send:

• The Quick Access pin itself (the dev folder)
• Same path typed into the picker
• Mapped drive: net use W: \\wsl.localhost\Ubuntu-24.04, picking W:\home\<user>\dev
• subst: subst X: \\wsl.localhost\Ubuntu-24.04\home\<user>\dev, picking X:\
• Symlink inside my home folder: C:\Users\<user>\dev is a symbolic link to the WSL path; picking C:\Users\<user>\dev

<img width="567" height="103" alt="Image" src="https://github.com/user-attachments/assets/535c7c6e-0620-4d62-b6c7-701c28d29fa1" />

In all five, the folder chip appears on the message, but sending fails with "Some folders couldn't be added. They were removed from this message." The folder is removed and the message does not send. Once (mapped drive), the chip was not removed despite the banner, and the message stayed blocked until I removed it by hand; I couldn't reproduce that again.

All of these paths work fine in Windows Explorer. The symlink case is notable: the path is inside the home directory, but it still fails once its target is resolved. And the same location gets different handling depending on depth: picking the dev folder fails at send, picking a folder inside it is rejected up front.

Keeping repos on the Linux filesystem is Microsoft's own recommendation for WSL ("For the fastest performance speed, store your files in the WSL file system if you are working in a Linux command line": https://learn.microsoft.com/en-us/windows/wsl/filesystems), so for WSL developers Cowork can't reach any of their projects.

Proposed Solution

Any of:

1. Accept \\wsl.localhost\<distro>\... folders in Cowork's picker and mount them.
2. A settings allowlist for extra workspace roots.
3. Follow the Code tab's approach and route WSL folders through the distro. The Code tab already handles this: picking a \\wsl.localhost\... folder reopens the session inside the distro (https://code.claude.com/docs/en/desktop-wsl). Cowork has no equivalent.

Alternative Solutions

• Moving repos to the Windows side: goes against Microsoft's WSL guidance above, so not workable for daily dev.
• Aliasing the WSL path: net use, subst, and a symbolic link in my home folder all fail as above (matching #61003).
• Current workarounds are all Claude Code, not Cowork: the Code tab / VS Code extension (which handle WSL natively), Remote Control to follow those sessions from the app or phone, and cloud sessions for code that's pushed to GitHub. None of them give Cowork itself (artifacts, connectors, scheduled tasks) access to WSL files, and cloud sessions can't see uncommitted or local-only work.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

1. My projects live in ~/dev inside WSL2 (Ubuntu-24.04).
2. I open Cowork and want it to work on one of them.
3. Add folder → browse into my Quick Access pin to dev and pick a project folder → "Network (UNC) paths are not supported here."
4. Pick the pinned dev folder itself, type the path, or use a mapped drive, subst drive, or my C:\Users\<user>\dev symlink → accepted by the picker, but the send fails, the folder is removed, and the message doesn't send.
5. Result: Cowork can't touch any of my code, so dev work has to go elsewhere.

Additional Context

Related:

• #61003 (closed by stale bot, locked): same bug; WSL paths rejected directly and via net use / subst
• #40361 (open): home-directory restriction blocks secondary drives; same root cause
• #87782 (closed): Code tab WSL reopen behaviour; opposite request

The real ask is WSL support (see Proposed Solution). If that isn't planned, at least make the failure consistent: right now the picker accepts the WSL dev folder (pinned or typed), mapped drives, subst drives and symlinks, then the whole message fails at send, while a subfolder of the same location is rejected up front; and once the banner said the folder "was removed" when it wasn't, leaving the message blocked until I removed it manually.

Environment: Windows 11 Pro 25H2 (OS build 26200.9457), WSL2 Ubuntu-24.04, Claude Desktop 2.19675.0.0 (Cowork)