[BUG] Cowork cannot mount directories on non-system drives (D:\, E:\, etc.) — even with user approval

Resolved 💬 3 comments Opened Mar 31, 2026 by ollanvin Closed Apr 3, 2026

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 refuses to mount directories located on non-system drives (D:\, E:\, etc.) on Windows.

Steps to reproduce:

  1. Store your projects on D:\ drive (e.g., D:\project\cardspend)
  2. 2. In Cowork, use request_cowork_directory or click "Select folder" to mount D:\project\cardspend
  3. 3. Cowork rejects with error: "Selected directory is outside the home directory and cannot be mounted."

Attempted workarounds (all failed):

  • Tried various path formats: D:\project\cardspend, D:/project/cardspend, D:\
  • - Created a Windows symlink: mklink /D C:\project D:\project — Cowork resolves the symlink to the real D:\ path and still rejects it
  • - - No combination of path or symlink tricks bypasses this restriction

Impact:
Many Windows power users and developers store projects on secondary drives (D:\, E:\) for storage management, SSD/HDD separation, or organizational reasons. This restriction makes Cowork unusable for their workflow, forcing either:

  • Moving all projects to C:\ (impractical for large codebases or when C:\ has limited space)
  • - Using git push/pull as a workaround to transfer files (defeats the purpose of direct file access in Cowork)

Environment:

  • Windows 11
  • - Claude Desktop (latest)
  • - - Cowork mode (research preview)
  • - - - D:\ drive is a local physical drive, not a network share

What Should Happen?

Cowork should allow mounting any local directory that the user explicitly approves, regardless of which physical drive it resides on (C:\, D:\, E:\, etc.).

Proposed behavior:

  1. When the user selects or specifies a directory on a non-system drive (e.g., D:\project\myapp), Cowork should mount it normally — the same way it mounts directories under C:\Users\
  2. 2. The existing user-approval dialog is sufficient as a security gate — no additional restrictions needed for local drives
  3. 3. Symlinks pointing to non-system drives should also be supported (resolve-and-reject defeats the purpose of the workaround)

Note: This restriction should only apply to network shares or truly external/untrusted paths — not to local physical drives that are part of the user's own machine.

Error Messages/Logs

Error from request_cowork_directory tool:
"Selected directory is outside the home directory and cannot be mounted."

Paths attempted:
- D:\project\cardspend
- D:/project/cardspend
- D:\
- C:\project (symlink to D:\project via mklink /D) — resolved to D:\ and rejected

Steps to Reproduce

  1. Have a Windows machine with a secondary local drive (D:\)
  2. 2. Store a project folder on D:\ (e.g., D:\project\cardspend)
  3. 3. Open Claude Desktop and start a Cowork session
  4. 4. Ask Claude to mount the project folder, or use "Select folder" to pick D:\project\cardspend
  5. 5. Cowork rejects: "Selected directory is outside the home directory and cannot be mounted."

Symlink workaround attempt:

  1. Open PowerShell as Admin: New-Item -ItemType SymbolicLink -Path C:\project -Target D:\project
  2. 2. Ask Cowork to mount C:\project\cardspend
  3. 3. Cowork resolves the symlink to D:\project\cardspend and still rejects it

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.87 (Claude Code) — via Cowork mode in Claude Desktop

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This issue affects all Windows users who store projects on non-C:\ drives. The current restriction assumes all user data lives under the home directory (C:\Users\), which is not true for many professional setups where D:\ or E:\ drives are used for development projects.

The user-approval dialog already exists as a security gate — there is no security benefit to additionally restricting which local physical drive the directory resides on.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗