[BUG] Cowork Windows home-directory folder restriction — unresolved regression, and every related issue has been closed without a fix

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?

[BUG] Cowork Windows home-directory folder restriction — unresolved regression, and every related issue has been closed without a fix

Summary

Since the 2026-02-16 update, Cowork on Windows rejects any workspace/project folder located outside C:\Users\<username>\. This broke setups that worked the day before, and it remains broken today. Every issue filed about this has been closed — several "as duplicate" of issues that are themselves closed, and at least one (#26103) has been locked to collaborators only, cutting off the users it affects from even commenting.

This report exists because there is currently no open, unlocked thread where affected Windows users can register this problem. That is the first thing that needs to change.

The problem

On Windows it is completely standard to keep the OS on C: and everything else — projects, data, workspaces — on secondary drives or dedicated paths (D:\, C:\Projects\, C:\<company>\, NAS mounts, mapped drives). This is not an edge case; it is how Windows is installed and used by most professional users.

Cowork's folder picker resolves the selected path with fs.realpath() and rejects anything that does not resolve under the user profile:

"The selected folder is outside your home directory. Only folders within your home directory can be used."

Notably, Claude Code's own folder picker (Code tab) has no such restriction and opens any OS-permitted path. So this is a Cowork-specific UI validation choice, not a platform or SDK limitation.

The security argument does not hold

We understand the intent is safety. It does not justify this restriction:

Once a session starts, the sandbox/VM mounts and reads/writes the selected folder regardless of where it lives. The home-directory check gates selection in the UI, not the actual access. It adds no real containment — the same file operations happen either way.
The Code tab already allows any accessible path with the same underlying engine. If arbitrary paths were a genuine security boundary, that path would be closed too. It isn't.
Real security here is explicit user consent per folder, which the permission model already provides. Blanket-blocking a drive letter is not a security control; it is a blunt UI gate that punishes legitimate use.

If there is a concern about system/program directories, block those — C:\Windows, Program Files, etc. Do not lock out entire drives and user-chosen project roots.

Failed workarounds (all confirmed non-viable)

NTFS junction: mklink /J "C:\Users\<user>\Work" "D:\Work" → rejected. fs.realpath() resolves to the real target and applies the same block.
Symlink: same result.
There is no supported way to whitelist a path in settings.

Timeline

✅ Working: 2026-02-15 (e.g. v1.1.3189)
❌ Broken: 2026-02-16 update onward
Still broken as of this report, with no official fix or acknowledgment of a plan.

The pattern that is the real issue here

This regression has been reported repeatedly, in detail, with reproductions — and closed each time without a resolution:

#26103 — doc04, the original regression report (2026-02-16). Closed and now locked. The follow-up comment by @phamtrungminhai-hash (2026-02-19) documented the D:-drive/symlink/junction failures cleanly. Locked out.
#24964 — folder picker rejects folders + symlinks/junctions. Closed.
#29583 — cannot use folders outside home on Windows (secondary drive). Closed.
#24927 — folder picker restricts non-home drives. Closed.
#38468 — feature request to remove the restriction. Closed as duplicate of #24964 (which is closed).
#43725 — registry-redirect workaround. Closed as duplicate of #24964 (which is closed).
#20550, #20382 — earlier reports of the same. Closed.

Closing a bug as a duplicate of another closed bug, then locking the origin thread, is not resolution. It reads as making the reports disappear rather than fixing the defect. That erodes the basic trust between users and the product. People built their workflows on documented, working behavior; a silent change removed it with no notice, no migration path, and now no open channel to be heard.

Real-world impact

This is not cosmetic. Affected users have:

Months of setup broken at once — vaults, git repos with automated sync, PARA/knowledge structures, and multiple linked projects rooted outside the home directory.
Real cost and real risk. The only "fix" offered is to relocate everything into C:\Users\..., which for git-tracked, tool-integrated, multi-project setups means re-cloning, re-pointing every integration, and re-granting every permission — an operation that itself risks breaking things that currently work. Users are being asked to absorb the cost of a change they did not ask for and were not warned about.
No viable in-place alternative, since symlinks/junctions are explicitly resolved and rejected.

Requested fix

Any one of these resolves it:

Preferred: Remove the home-directory restriction on Windows and allow any path the OS user has read/write access to — matching Claude Code's existing behavior.
At minimum: Add a Settings option to whitelist additional trusted root paths (e.g. an allowedWorkspaceFolders / allowedDirectories array, as the Filesystem MCP server already supports).
Or: Accept symlinks/junctions by not resolving via fs.realpath() before validation, giving users a supported opt-in workaround.

And, separately from the code fix: please reopen or provide a single tracking thread that stays open and unlocked, so the affected user base has somewhere legitimate to follow this and be counted.

Environment

OS: Windows 11
Product: Claude Desktop — Cowork tab
Regression introduced: 2026-02-16 update
Reproducible: yes, every session, on any path outside C:\Users\<username>\

Filed because the existing reports (#26103 and its duplicates) were closed and locked, leaving no open channel for this widespread, still-unresolved Windows regression.

What Should Happen?

<img width="521" height="150" alt="Image" src="https://github.com/user-attachments/assets/a0623401-ea97-4b79-8039-f6f458ece867" />

Error Messages/Logs

checking my filesystem:
/mnt/user-data   ->  No such file or directory  (DOES NOT EXIST)
/mnt             ->  contains only: skills
mount | grep rodhe/recaud/user-data  ->  (no mount for the project folder)
The only files in my workspace are the ones attached directly to the chat — nothing pulled from the connected folder or its originales subfolder.

Steps to Reproduce

Steps to Reproduce
Environment

Product: Claude desktop app — Cowork (cloud session)
App version: 1.19367.0
OS: Windows
Connected folder: C:\CoworkFolder\Projects\project_1

Steps

Open the Claude desktop app and start a Cowork session.
Connect a local folder via Add folder: C:\CoworkFolder\Projects\project_1. Put a test file inside it (e.g. project_1\sample.pdf).
Call get_device_info to confirm the bridge is connected. It succeeds:

json {
"deviceName": "my-device",
"connectedFolders": ["C:\\CoworkFolder\\Projects\\project_1"]
}

Ask the assistant to read or list a file from that folder without attaching it (e.g. "list the project folder" or "read project_1\sample.pdf").
The file tools (device_list_dir, device_stage_files, device_commit_files) fail to load:

No matching deferred tools found

Confirm nothing was mounted:

bash ls /mnt/user-data
# -> No such file or directory
Expected result
With the folder connected, the assistant should list it (device_list_dir), pull files into the workspace (device_stage_files), and write results back (device_commit_files) — no manual attachment needed.
Actual result
Only get_device_info works. The file tools never load and /mnt/user-data doesn't exist, so the assistant sees the folder's name but can't access its contents.
Frequency: 100% reproducible, survives app restarts and folder reconnects.
Workaround: manually attaching files to the chat works.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Working: 2026-02-15 (e.g. v1.1.3189)

Claude Code Version

e.g. v1.1.3189

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Here's an Additional Information section you can paste in:

Additional Information
Diagnostic evidence (from the session environment)
Connection ping works, file tools do not:
bash# get_device_info -> SUCCESS
{ "deviceName": "my-device",
"connectedFolders": ["C:\\CoworkFolder\\Projects\\project_1"] }

Loading file tools -> FAILS

device_list_dir / device_stage_files / device_commit_files / project_memory_read / project_memory_write
-> "No matching deferred tools found"

Session filesystem

ls /mnt/user-data -> No such file or directory
ls /mnt -> only: skills
mount | grep user-data -> (no mount for the connected folder)
Key detail: The remote-devices connector loads in "info-only" mode — get_device_info is the only tool exposed. The file-transfer and project-memory tools are never registered, so the folder is visible by name but not by content.
What was tried (issue persisted through all of these):

Fully quitting and reopening the desktop app
Reconnecting the folder via Add folder
Re-checking get_device_info (always reports the folder as connected)
Multiple retries across ~several hours in the same session

Confirmed working workaround: Files attached directly to the chat are readable; they land under /root/.claude/uploads/.... Everything produced in-session had to be delivered back through the chat rather than written to the connected folder.
Screenshots to include (drag & drop):

The desktop app showing the folder connected under Cowork
The assistant's message stating the file channel is unavailable

Configuration files: None required — reproducible with any connected folder containing one test file.
Related files / repositories: Not applicable — no code needed; occurs with a plain folder + a single .pdf/.docx inside it.
Suggested severity: Medium–High — the connected-folder feature is effectively non-functional (read + write both blocked); chat attachments are the only workaround.