[BUG] Cowork: `request_cowork_directory` rejects WSL2-backed paths even when aliased via `subst` or `net use`

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?

My 100% human-written summary of the problem:

Claude Cowork for Windows cannot share WSL2 directories, even using net use or subst. I do all my Real Work in WSL2. Windows is basically an employer-mandated OS layer that I don't understand, and in which I run nothing except a web browser and terminal sessions, and VSCode connected to WSL2 remotes Because of this, I have to either: 1. Symlink WIndows directories into WSL2. E.g. ln -s /mnt/c/Users/foo/whatever ~/whatever. These are painfully horrifyingly slow especially when manipulating the kind of huge "symlink farms" that Python virtualenvs and Rust cargo use. 2. Create a "drop zone" for passing files back and forth with Claude. This is a tedious and annoying mess. It's basically a one-man, one-robot sneakernet.

Claude Cowork produced its own summary of the problem, after discussing it together:

Platform: Windows 11 + WSL2 (Ubuntu), Claude desktop app, Cowork research preview Behavior: The Cowork sandbox's request_cowork_directory tool refuses any path whose underlying target is a \\wsl.localhost\… (or \\wsl$\…) UNC share, regardless of how the user presents the path. The validator resolves drive-letter aliases back to their UNC target before applying the check, so all of these are rejected with UNC paths are not supported: - Direct: \\wsl.localhost\Ubuntu\home\dlenski\xparts - Drive letter via net use W: \\wsl.localhost\Ubuntu: W:\home\dlenski\xparts - Drive letter via subst W: \\wsl.localhost\Ubuntu\home\dlenski: W:\xparts Impact: WSL2 users can't share a WSL2-resident project directory with Cowork. The only workaround is to keep the project on C:\ (which is unworkable for Python toolchains like pixi/uv whose symlink-heavy environments perform terribly on /mnt/c/) or to manually rsync Cowork output between a Windows drop-zone folder and the real ext4 repo. Request: Either accept opt-in mounts of WSL2 paths (perhaps gated behind a confirmation dialog warning about cross-FS semantics), or document this limitation prominently. As written, the validator's resolve-then-check behavior is robust against every common aliasing trick (net use, subst, mklink /D with UNC target), so users have no escape hatch.

What Should Happen?

Claude Cowork running on Windows should be able to share WSL2 directories with its users.

Steps to Reproduce

1. Create a directory in WSL2.
2. Attempt to share it with Claude Cowork.

Claude Model

Opus 4.7, but _almost certainly not relevant_

Is this a regression?

I don't know

Last Working Version

Unknown

Claude Code Version

Cowork Version 1.7196.0 (2dbd78)

Platform

Anthropic API

Operating System

Windows 11

Terminal/Shell

Cowork + Windows Terminal WSL2 tab

Additional Information

_No response_