[BUG] Cowork: Cannot use folders outside home directory on Windows (secondary drive)

Same on mac

Junctions also fails. This needs to be fixed!

Facing same issue for Cowork. This issue looks similar to https://github.com/anthropics/claude-code/issues/20382 which is now closed

<img width="826" height="675" alt="Image" src="https://github.com/user-attachments/assets/02409914-71ff-4207-a571-aede40c42ab2" />

Same here on Mac. I have an external drive 1T that I need to work with but it fails because Claude only wants to use my local home directory. Please fix this.

Did someone find a fix yet?

have the same issue

Same. Windows allows you to explicitly move your various libraries (My Documents, My Downloads, etc) to another drive, a common practice to keep user and system data separate, and this breaks Cowork completely. My home directory on C:\ basically only contains AppData.

Following having the same issue Mac OS

I also would like to use Co Work outside of my Home directory, is there no option for this?

I have the same issue with having redirected my Desktop folder to a different drive, and can't target it with Cowork.

Even more crazy, Claude Desktop has saved its scheduled tasks in D:\OneDrive\Documents\Claude for me, which is outside it's home directory and the tasks cannot access them... so all scheduled tasks now don't know what they are doing and fail!

Struggling with the same issue on mac. Think this needs to be pushed up a little higher

Frustrating to me, is there a possible workaround via /add dir or such?

+1 to this. using mac

This is annoyingly weird. Symlink doesn't help.

Same issue here. still not resolved.

Same issue here, previous MCP Server workaround also not working any more.

I use pCloud for my Documents, all in a P: drive. I cannot use this unit and any of its folders.

This sucks. Needs to be fixed ASAP!

Need the fix ASAP.

Same issue here, Windows 11, Claude 1.1.5368 (d12d02) 2026-03-05T17:29:33.000Z

Please resolve this issue. I'm not sure how put in my vote but this is a serious limitation. Thanks

I understand the design choice, but all my projects are on D: drive! Need a away to explicitly add trusted folders.

please fix this quickly!

It is clearly not a bug but a design decision. I would kindly ask you to at least support symlinks.

Same here, please address. Not supporting symlinks for security makes sense but give us something to work with please.

Same here, Please fix this ASAP, or else Cowork is almost useless.

Face this same problem too in macOS. Network drive mounted via smb:// protocol (appears as /Volumes/... in file system) is unable to be accessed by Cowork.

+10000000 to this. It's ridiculous.

I have to tell you, I love using Claude and would love it even more if there was a way to use this on my development machine without being limited to the using the User's folder for projects. I intentionally run a smaller SSD RAID for my Boot/OS drive with 60 TB of storage with multiple partitions for projects, source code, VMs, and other assorted data. This is the ONLY place I would consider putting CoWork projets. It's my data and my drives, so don't force me to put stuff in places that don't make any sense. I can't even begin to imagine why anyone would consider this limitation was a good idea.

Until Anthropic fixes this very serious limitation, then the desktop version of this along with CoWork is completely useless to me.

Are you listening, Anthropic?

Support other locations and dev drive feature please.

Same problem here

same problem on win11, hope it could be fixed soon

This needs to be fixed !

Same problem, does not work with ReFS drive on Win 11

Confirmed on Win 10 with partitioned drives. This is a significant blocker for Windows users with standard multi-drive setups (separate OS and data drives is extremely common in content producer/developer/enterprise environments).

Would love even a temporary opt-in flag or an "advanced folder access" toggle as an interim fix. Happy to test any builds.

Same, please fix this, otherwise it is very hard to use.

same here !

Adding another voice to the chorus. Went to use Cowork on D drive this morning only to find out I can't. Claude itself even suggested the symbolic link which then didn't work. My mom has a secondary drive with data stored on it, this is not a super elite technical feature. Come on now.

Same here.

I do hope this is a bug and not a business decision, as this is nuts!

I'm not moving all my stuff into my profile directory on windows, what nutter is going to do that, to use this tool??

Same here...

⚠ URGENT: Confirmed Bug — Cowork Folder Path Restriction (GitHub Issues #29583, #24964, #27697)
This constraint renders paid cloud storage inoperable within Cowork automation workflows.
It directly affects enterprise and power users with proper, best-practice storage configurations.
Prompt resolution is requested. This report is being submitted to both the Anthropic product team and GitHub.

I have developed an automation workflow within Claude Cowork that processes qualified email exports using Microsoft Power Automate (FLOW). The workflow depends on the following architecture:

• Microsoft FLOW exports qualifying emails and attachments directly to OneDrive (this is a platform constraint of Power Automate — it cannot export to arbitrary local paths).
• Cowork automation must then access those exported files from within a designated working directory.
• For Cowork to read and act on those files, the working directory must be accessible to the Cowork application.

This is a fully rational, professionally designed workflow — and it works, in principle. The problem is introduced by how Cowork validates and restricts its working directory.

3.1 What Cowork Requires
Cowork’s folder picker restricts the working directory to paths within C:\Users\[Username]\ (the USERPROFILE). Any path outside this location — including other drives, external storage, or symbolic links/junction points — is rejected.

3.2 Why This Creates an Untenable Conflict
OneDrive, when configured through Microsoft’s standard M365 setup, syncs to a folder within the user’s profile directory: typically C:\Users\[Username]\OneDrive. This means:

• The OneDrive sync folder is inside the USERPROFILE — so it satisfies Cowork’s path restriction.
• However, OneDrive sync consumes space on the C: drive proportional to what is stored or synced.
• On a machine with a 1 TB system drive and 5 TB of OneDrive cloud storage, full sync would exceed the C: drive capacity — effectively making paid cloud storage unusable.
• Best practice for enterprise Windows 11 systems is to limit system drive usage to the operating system and essential system files. Large data stores — including cloud sync folders — should reside on secondary drives with adequate capacity.

The result: either the system drive is overwhelmed, or the automation workflow fails. There is no option within the current Cowork design that satisfies both requirements simultaneously.

Cowork resolves symbolic links and junction points to their actual target path before validation, then rejects them because the real path is outside the USERPROFILE. This is not a user error — it is a confirmed Anthropic application behavior documented in GitHub issues.

This is not an edge case. The affected user profile — enterprise-grade system, M365 subscription, cloud-integrated automation workflows — represents a core segment of Anthropic’s target MAX-tier developer and professional audience. The impact extends broadly.

The following resolution is respectfully but urgently requested:

• Remove or relax the USERPROFILE path restriction in Cowork’s folder picker to allow any locally accessible path, including other drive letters and network-mapped locations.
• If security constraints require path validation, implement an allowlist mechanism that enterprise users can configure, rather than a hard-coded rejection of paths outside USERPROFILE.
• At minimum, honor symbolic links and junction points that resolve to accessible local paths, rather than rejecting them based on the resolved target.
• Provide status communication on GitHub Issues #29583, #24964, and #27697, including a target resolution milestone.

same here!

I have a E:\Fotos folder with 500GB of photos that I need to work with in Cowork. Moving it to C: is not an option due to insufficient disk space, and the symlink/junction workaround doesn't work as confirmed in this report.
This is a deal breaker for anyone with large collections or projects stored on secondary drives, which is extremely common precisely because C: runs out of space. Until this is resolved, Cowork is simply unusable for my main use case.
Please prioritize this. It's a fundamental limitation that blocks real workflows, not an edge case.

Yeah this is a significant blocker for me & there's gotta be a better way to do sandboxing if that's the design intent

I have a small SSD running the OS and otherwise always work on other drives and I think this is a common enough setup

same here!

Same here, need a fix to use a secondary dedicated drive (D) in W11 Pro

Title: Cowork cannot access folders on secondary drives or networked storage — defeats the purpose
Description:
Cowork is supposed to be a collaborator that works with your actual project files. Instead, it's locked to the home directory and rejects secondary drives (E:, F:, etc.) and networked locations like OneDrive or network shares. This forces users to either:

Keep all projects under ~100GB on the C: drive (most people can't — that's for Windows and software)
Copy 50GB+ to a temporary location, wait for analysis, then move it back
Give up and work in Cowork's sandbox workspace instead

A user with J:\OneDrive\Projects (Microsoft's default OneDrive structure) or E:\GoogleDrive (Google Drive mounted to a secondary drive) cannot use Cowork at all. This is the standard setup for anyone with >100GB of projects.

The net effect: Cowork becomes a segregated work environment instead of a collaborator. A real coworker can log into your computer and open files wherever they are. This can't.
The workaround requires mounting drives via Disk Management, which is several steps removed from "seamless collaboration."
What should happen:
Cowork should prompt users to grant access to any folder they select, regardless of drive location. Permission once, work everywhere. This is table-stakes for a local AI tool.
Current state:

✓ Can access /Users/john/Documents/projects
✗ Cannot access E:\Archive\Active_Projects (rejects with "outside home directory")
✗ Cannot access network shares or OneDrive folders
✗ Cannot work with symlinks (resolves and rejects the target)

Same here. In MacOS
RPC error: failed to mount ../khoilq/ClaudeCowork/VinamilkPJ as VinamilkPJ: source path does not exist and could not be created: /mnt/.virtiofs-root/khoilq/ClaudeCowork/VinamilkPJ: mkdir /mnt/.virtiofs-root/khoilq: operation not permitted

need fix please ASAP - win 11

I'm paying for two Claude Max plans ($200/each) and can't use Cowork with any of my project data because it all lives on my D: drive. My C: drive has nothing useful on it. Asking users to duplicate terabytes of data or relocate their entire Windows profile to work around this restriction isn't reasonable. This needs to be prioritized. @ah-anthropic

Agreed. This is limiting enterprise usage at our company. This needs to be
fixed.

Book a meeting <https://calendar.app.google/NvSHjFn3ZzZw7GsN7>

Trevor MarstellerController

Cash and credit powered by your potential
www.tilt.com

<https://x.com/tilt> <https://www.linkedin.com/company/tilthq>

On Sun, Mar 15, 2026 at 12:46 PM BLEAK @.***> wrote:

craigvc left a comment (anthropics/claude-code#29583) <https://github.com/anthropics/claude-code/issues/29583#issuecomment-4063381377> I'm paying for two Claude Max plans ($200/each) and can't use Cowork with any of my project data because it all lives on my D: drive. My C: drive has nothing useful on it. Asking users to duplicate terabytes of data or relocate their entire Windows profile to work around this restriction isn't reasonable. This needs to be prioritized. @ah-anthropic <https://github.com/ah-anthropic> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/29583#issuecomment-4063381377>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX434CC5KAHGVEIJJ7XVXM34Q3M6HAVCNFSM6AAAAACWCTR5AGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRTGM4DCMZXG4> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

This makes Cowork absolutely useless, been trying to set it up for my father that works in law and he can't use it because documents are in a D folder.

As a developer I use Claude Code everyday but it's appalling how bad the setup experience is for a non developer. And even after going through the hoops, it's totally unusable because of this for which there is no workaround, as allegedly even symlinking doesn't fix the issue.

Would be great to know if this is a confirmed design choice that won't be changed, or if it's at least being considered on a bug/feature log somewhere. It's the only reason I don't use Cowork nor recommend it.

Same here, macOS and windows, this makes Cowork useless for me...

Cowork is essentially useless in a real work environment until this is resolved. I had tried a couple weeks ago thinking this must be high priority bug that would obviously be fixed, but tried again today, and still not working. I want to roll Cowork out to our entire team, but have put it on hold until this is resolved, since almost no business use case occurs inside a user's personal folder.

This is a wild design choice. My 77-year-old mother has a D:\ drive, for pity's sake. I cannot move any projects of consequence into my C:\ structure for lack of space. (Windows is a needy OS.) Please fix this. C:\ is actually the one drive I do NOT want Cowork touching. That's my OS!

same here,need fix please

Still waiting for company comments. Not usable right now.

Same, been waiting for weeks. Would really appreciate them fixing this!

FIX THIS NONSENSE. Projects, files, things we use have always been outside "home" directories since the dawn of the PC. If we grant access to a folder it should have access to the folder. Cowork is unusable until this is fixed.

This is laughable as a workable product.

Who in management signed off on this shit?

Totally agree. My guess is they might not have the capacity to handle a surge in usage if this restriction is lifted. I have quite a bit of work lined up with Cowork that would be much easier if I could access folders outside my user directory. Also, Claude has been noticeably less stable lately, and it feels like outages are happening more often than before.

Up vote this

I really hope this is not a business decision, but a bug. It would be nice if someone replied

is there a fix for this

I use Dropbox for cloud storage, but my Dropbox root folder is located on my D: drive (D:\Dropbox) rather than the default C:\Users path. This is a common configuration for users who keep their C: drive lean by offloading large sync folders to a secondary drive.

Because Cowork currently restricts folder access to C:\Users, I have no path to integrate my Dropbox files with Cowork until this issue is resolved. Manually uploading files is the only workaround, which significantly limits Cowork's utility for this use case.

Hoping this concrete example helps illustrate the impact and prioritize a fix. Thanks for working on it.

Another user affected — D: drive on Windows

I'm hitting this exact limitation. I keep all my development projects on a dedicated D:\ drive, specifically to keep them separate from the Windows system partition (C:\) for safety and organization purposes. This is a very common and recommended setup among Windows developers.

When I try to select D:\browser_automation\be_explorer in Cowork's folder picker, I get:

"Selected directory is outside the home directory and cannot be mounted."

I also tried using the programmatic request_cowork_directory tool with the explicit path — same result. Symbolic links and directory junctions don't work either, since the path is resolved to its real target before validation.

Why this matters: Many Windows users deliberately use a secondary drive for projects. Restricting Cowork to %USERPROFILE% makes it unusable for a significant portion of the user base without forcing them to restructure their entire workflow.

Suggested fix: Allow users to configure a list of trusted directories (similar to allowedDirectories in the Filesystem MCP server), or at least let the user explicitly approve access to any folder through the native picker without the home-directory check.

Would love to see this addressed — Cowork is a great tool, but this restriction is a dealbreaker for my workflow.

<p>Another affected user here — also using a dedicated <strong>D:</strong> drive on Windows.</p>

<p>I intentionally keep all my development projects and repositories on a separate <strong>D:\</strong> drive. This setup:</p>
<ul>
<li>Keeps the system partition (<code>C:\</code>) clean and lightweight</li>
<li>Reduces unnecessary writes to the OS SSD</li>
<li>Makes backups, disk imaging, and project separation much cleaner</li>
</ul>
<p>This is a very common (and frequently recommended) layout among Windows developers.</p>

<p>However, when I try to select a folder such as <code>D:\dev\my-project-folder</code> in Cowork's folder picker, I immediately get the error:</p>

<blockquote>
<strong>"Selected directory is outside the home directory and cannot be mounted."</strong>
</blockquote>

<p>The same rejection happens when using the programmatic <code>request_cowork_directory</code> tool with an explicit full path. I also tried creating NTFS directory junctions and symbolic links from inside <code>%USERPROFILE%</code> — Cowork resolves the real target path and still blocks it.</p>

<p><strong>Why this is a serious problem:</strong><br>
This restriction forces many Windows users to either:</p>
<ul>
<li>Move all projects back under <code>C:\Users\…</code> (undoing a deliberate, battle-tested organization strategy)</li>
<li>Abandon Cowork entirely</li>
</ul>

<p><strong>Suggested improvements (pick one or both):</strong></p>
<ol>
<li>Allow users to configure a list of <strong>trusted root directories</strong> (similar to <code>allowedDirectories</code> in the Filesystem MCP server / many secure file APIs)</li>
<li>When the user selects a folder via the native OS folder picker, offer a <strong>one-time confirmation dialog</strong> for non-home locations instead of a hard block</li>
</ol>

<p>Cowork looks extremely promising overall — this single limitation is currently a complete dealbreaker for my (and many other developers') daily workflow. Please consider making this configurable or at least more flexible.</p>

hitting the same issue on Cowork in Windows, it's completely ridiculous and makes Cowork worthless (for me personaly). And the fact that this basic showstoping bug is now ignored by a company like Antropic for WEEKS is completely unacceptable and ridiculous.

I am also affected by this bug. I would like to use Claude Cowork with a folder on an external hard drive, but the current restriction to the home directory makes this impossible.

This is a significant limitation for users who store their working files on external drives — a very common setup. Please prioritize a fix for this as soon as possible. Cowork seems like an excellent addition to Claude's impressive capabilities. But this bug is making it difficult to use it. Looking forward to seeing this resolved soon.

I was able to do some tasks on other drives when using the Dispatch option.

But this is still not the solution.

<img width="1051" height="436" alt="Image" src="https://github.com/user-attachments/assets/8962ece4-f61b-40a9-b817-49ecfa25977c" />

Upvoting this issue. Restricting Claude Cowork to the %USERPROFILE% directory significantly limits its usefulness; there should be support for accessing other paths on your computer.

Same issue. I do not like to keep a "working" dir in my user folder. I like to keep my C: drive minimal with program installations only. All data should reside on D: drive.

Same issue, my harddisk drive C:\ only have 128 gb :(

Same here. I read somewhere that this is by design for security reasons. But just like every other feature in Claude, just ask the Question and let the user decide to either grant permission or not. Need to be consistent with your security measures.

same issue here, and this sucks because this is a major reason i cannot reasonably use cowork. my C:/ is os only, my D:/ is ALL of my data and what i need it to work with. Full stop it cannot, the sandboxing limits are ridiculous, let me configure what i believe my sandbox needs are.

use dispatch, can be a workaround. but definitely any folder selection must be an option

Same. Windows allows you to explicitly move your various libraries (My Documents, My Downloads, etc) to another drive, a common practice to keep user and system data separate, and this breaks Cowork completely. My home directory on C:\ basically only contains AppData.

I've run into that as well. I got a new larger drive "D" and repointed Windows default locations to it d:\user\myname\documents etc.

• seems, that if it's not "C", CoWork won't work with it. It should be ok with whatever folder the computer has registered as home.

According to Claude.ai:

What's happening technically

The folder picker uses os.homedir() to determine the home directory and then checks whether any selected path falls within it. The check uses path.relative() and fs.realpath() - so if the result is an absolute path or starts with "..", the selection is rejected. GitHub The problem is that os.homedir() on Windows returns the hardcoded C:\Users\<username> path regardless of whether you've relocated your user profile to another drive.

What you can do

Vote/comment on the GitHub issues - The more people engage with them, the higher priority they tend to receive. The most active thread appears to be issue #24964.
Use the thumbs-down feedback button in Claude Desktop to flag this as a problem.
Wait for a fix - given the volume of reports, this seems likely to be addressed in an upcoming update.

It's a legitimate gap - the safety logic is reasonable in principle (limiting access to the user's own files), but it simply doesn't account for Windows users who have moved their profile or store work files on a secondary drive, which is quite common.

Pretty critical usecase here, sitting for over a month.

Cowork is dead in the water on the basis of this.

People do not typically use their home folder or user folder in this way on Windows and the commonness of second drives is a breaking issue. There's deep paradigm difference in Code, Cowork, and Dispatch, which is fine, but only Code really fits the reality of use (with run dangerously being treated as a default by many due to their ability to safely sandbox on their own).

Real-world impact: this limitation makes Cowork unusable for many Windows users

My home directory is D:\Users\myname\ - a completely normal setup for Windows users who store data on a secondary drive. Because Cowork hard-codes its restriction to whatever %USERPROFILE% resolves to (in my case C:\Users\myname\), I cannot use Cowork with any of my actual files.
The suggested workarounds all involve a dangerous copy-work-copy-back workflow:

"Organize my Downloads folder" - I'd need to copy potentially gigabytes of files to C:, let Cowork organize them, then delete the originals and copy back. One mistake = data loss.
"Help me with my accounting" - same problem, but now I also have sensitive financial data sitting in two places.

This isn't a niche edge case. A large number of Windows users keep their data on a D: drive, either because they partitioned their SSD that way, use a secondary HDD for storage, or simply prefer to keep their OS and data separate. For all of these users, Cowork is essentially non-functional for any real work.
The fix doesn't need to be "allow access to everything" - just allow users to explicitly select and authorize folders outside %USERPROFILE%, the same way any normal file picker works. The safety intent is understandable; the current implementation is too blunt.

The same problem exists on Mac. For Mac, Claude found a workaround that works great, described below.

I don't think the notion of "bind mounts" exists for Windows, but maybe this can help find a similar solution.

p.s. It is ridiculous that Claude Cowork cannot whitelist folders in which to work (ChatGPT does it!). Just ask the user!
And by the way, the default of allowing any folder in the Home directory is not a sensible default. All sensitive data is stored in your home and could be exfiltrated by malicious prompts. And as mentioned by many above, professionals never store project data in the home. So it appears that Claude Cowork encourages the bad practices, and forbids the best practices!

---

Workaround: NFS loopback mount

Claude Cowork requires real paths inside $HOME, which breaks when your project lives on an external drive. On macOS, you can work around this by NFS-mounting the external drive path onto a directory inside $HOME. This creates a real mount point, so realpath returns the ~/... path rather than /Volumes/....

# Export the external drive path via NFS (replace 501 with your UID: `id -u`)
echo '/Volumes/YourDrive/project -alldirs -mapall=501 localhost' | sudo tee -a /etc/exports

# Restart nfsd
sudo nfsd restart

# Create mount point and mount
mkdir -p ~/project
sudo mount_nfs -o locallocks localhost:/Volumes/YourDrive/project ~/project

Note: this command might differ based on OS X version. The above works on Sequoia. Ask Claude to adapt the commands to your system.

yes please fix this, meanwhile I'll set up a copy of my documents folder inside the home, just to for cowork.. not the best solution
thanks!!

Merging this into #24964 for tracking purposes. As mentioned in that issue this is non-trivial but we're working on it 👍

I just encountered this issue on Windows desktop. Jeez

Merging this into #24964 for tracking purposes. As mentioned in that issue this is non-trivial but we're working on it

Big thanks, please fix it

This is absolutely needed or this is a useless feature.
Every professional user will have all their files on different folders/drives and specifically NEVER in the users folder.

Fix this, Anthropic, for God's sake! I haven't seen any Windows professional user store their work files under the User folder on the C drive; only my Grandpa might do that! Come on, who are you really targeting?

I think they are not fixing this so they can save compute resources.

They know as soon as this works the demand will go through the roof.

This sounds more like a business decision to delay.

This needs to be reopened and fixed - can´t use my subscription as intended. Will cancel if persistent.

I have a file on another drive that I couldn't get Cowork to access. I even asked it to look for the directory in D:/ and it said "I don't see it in your workspace." So I tried to add it to the workspace and got the error message we are all getting. Anyway..

Ask Claude inside cowork to find the file. Literally all I told it was "it's there on the D:/ drive" after it said it couldn't see it. It said "got it i need you to grant me access" and a prompt came up giving me the ability to grant it access to the folder.

So ask it this "can you prompt me to give you access to D:/folder" or whatever your folder location is. It won't work with root drives. Works with folders.

Of the 3 that were open on this topic, only this one is still open:
https://github.com/anthropics/claude-code/issues/24964

I'm a single developer and CEO of my own development company and all of my project work is on a different drive than my C boot drive on Windows, which is best practice as anyone in development working on local development would know (you'd think), and this makes it extremely clunky for me to manage. This is a simple fix. In my view and as a former CTO/CIO and lead developer and data architect, this is ridiculous from a company as good as Claude.ai is. The little things matter and in my case, this makes the tool virtually unusable.

since the update of about a week ago, the issue is fixed. I was using Cowork in folders on my D drive with no issue.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.