[BUG] Cowork: Folder picker rejects folders outside home directory, symlinks/junctions also blocked

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/24927

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is honestly very unsmart to limit that. It must be fixed ASAP it is not usable right now. User must control where AI has access not the other way around.

Additional impact: Windows Known Folder Redirection (not just project folders)

This restriction also breaks access to standard user folders (Documents, Desktop, Downloads) for anyone using Windows' built-in Known Folder Redirection — a core Windows feature since Vista that allows relocating shell folders to any drive.

This is not an OneDrive-specific feature. Known Folder Redirection has three independent mechanisms:

1. Manual — Right-click Documents → Properties → Location → move to D:\Documents
2. Group Policy — enterprise Folder Redirection policy
3. OneDrive KFM — "Back up my folders" (just one consumer of the same underlying mechanism)

Many users relocate their user data folders to a second drive as basic disk hygiene (smaller SSD for OS, larger drive for data). This is a well-established Windows practice that long predates OneDrive.

Why os.homedir() is the wrong check:

os.homedir() returns USERPROFILE, which is always C:\Users\<username> — even when the user's actual data folders (Documents, Desktop, Downloads) have been legitimately relocated to another drive via any of the mechanisms above. Windows itself tracks these relocated paths through:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
• The SHGetKnownFolderPath API

So the validation isn't just blocking "project folders on another drive" — it's blocking the user's own Documents folder if they've used a built-in Windows feature to move it.

My specific setup:

• USERPROFILE: C:\Users\LP
• OneDrive root: D:\UF\LP\OneDrive (non-default location)
• Documents, Desktop, Downloads: all redirected into OneDrive on D:\
• Symlink at C:\Users\LP\Claude-Work → D:\UF\LP\OneDrive\Claude-Work: rejected by Cowork (resolved via fs.realpath())

Every folder I'd want to use with Cowork is on D:\, and there's no workaround because fs.realpath() resolves both symlinks and NTFS junctions before the home-directory check.

Suggested fix direction:

Rather than checking against os.homedir(), the validation could:

• Query the actual known folder paths via SHGetKnownFolderPath (or the Node.js equivalent) and accept any path under those, OR
• Accept any path the user has OS-level read/write access to (the sandbox/VM can already access these paths once a session starts), OR
• At minimum, skip fs.realpath() resolution so that symlinks/junctions under the home directory work as intended

Related: #25162 (Squirrel-to-MSIX migration failure — same user, same Windows 11 Home setup)

I'm currently unable to use Cowork for the reasons stated by @Tjeef . I have Windows and apps installed on a fast M.2 and everything else on other drives. I have Documents/Pictures/Videos/Downloads all pointing to other drives, which as noted above is a feature officially supported by Windows.

<img width="452" height="244" alt="Image" src="https://github.com/user-attachments/assets/9759050f-9e27-4fff-97f3-9c295d6fbb60" />

Need this fixed. This is keeping me from being able to effectively use cowork because my projects and main documents dir Are not in my user directory.

Completely unusable like this, my home folder is practically empty. The C drive is small so I moved all the default folders to a second drive.

Cowork itself is not aware of this issue as it instructs you to use the folder icon to update the active folder.
This needs to be corrected.

Die Fehlermeldung „Der ausgewählte Ordner befindet sich außerhalb Ihres Benutzerverzeichnisses“ bedeutet:

👉 Claude Cowork (Windows) darf aktuell nur Ordner innerhalb deines Benutzerprofils freigeben.
Also nur unter:

Das ist eine harte Sicherheitsgrenze der aktuellen Windows‑Version von Cowork.
Root‑Laufwerke (C:\, D:\, E:\ …) können NICHT direkt freigegeben werden.

So ist Cowork unter windows nicht wirklich zu nutzen

I'm currently unable to use Cowork for the reasons stated by @Tjeef . I have Windows and apps installed on a fast M.2 and everything else on other drives. I have Documents/Pictures/Videos/Downloads all pointing to other drives, which as noted above is a feature officially supported by Windows.

Yes, same. It is a complete blocker for using the app for anything meaningful.

Same for me... I can use Claude Code in non home directories. It's bizarre Cowork does work (;)) the same way.

Same here. They need fix it ASAP.

Same issue.

Complete and utter show stopper. I'd been waiting for the Windows release, but Cowork is useless to me like this.
I keep literally nothing in my home folder (that I can avoid). It's all on additional non-OS drives.

Gotta join the me-too crown on this one. I was so dissapoint today when I went to try to use cowork and ran smack into this error. As others state, especially for devs, we work on the non-OS drives and keep next to nothing in the OS Home folder!!!

Huge dissapointment.
Interestingly, Claude Code Desktop lets you pick any folder anywhere, so was shocked when cowork had this limitation.

I do not use Windows Home. I reserve the C: partition for Windows and wipe it every time I need a fresh installation. I store all my data on drive D:.

I know what I’m doing. It would be nice if CoWork allowed me to work on my files instead of the trash my home folder becomes.

Absolute deal breaker. Please fix.

New customer, very disappointed. Claude is litterally drowing their baby in stupidity. The very presumption and conceited self-authority that goes into making such a restriction in the first place is something any company needs to be wary.

Yes, this needs to be fixed.

Same issue. Cowork is completely useless if all I can access is my system files.

Coworkへの読み込みで外付けHDD（F:ドライブ）のフォルダーが選択できません。修正をお願いします。

Ridiculous issue that kills functionality for those of us using a small drive for OS and larger drives for anything else.

Yes, this is crazy. It needs to be resolved; no user with a brain stores any of their files in the home directory.

Cowork is litterally unusable whilst this issue exists.

How do we know it's a bug rather than intended functionality? I agree that this is stupid. We should be allowed to determine where it works. Has Anthropic said anything about what their intended behavior is meant to be?

Claude CoWork on windows is unfortunately a buggy alpha version. Massive disappointment that gives AI a bad name.

Hey folks, just chiming in here that this is currently an intended behaviour for various reasons. However, we are looking at how we can let folks using external drives or non-standard folders, the usage of which definitely seems more prevalent amongst our windows users.

Hey folks, just chiming in here that this is currently an intended behaviour for various reasons. However, we are looking at how we can let folks using external drives or non-standard folders, the usage of which definitely seems more prevalent amongst our windows users.

We appreciate the consideration @MarshallOfSound
But I think it's fair to say this is not only a Windows issue. I doubt I'm alone in saying on Linux I also rarely use the home directory by choice.

Can we at least have the option to 'lock' agent access to a chosen drive or sub-directory scope?
Functionally, bar any file access that violates the chosen tree prefix?
Can that be done at the agent tool level?

Not sure if it was clear from my relabelling but yes we're looking at how to support this on both platforms cowork supports (macOS and Windows).

It's unfortunately more complex than just changing some paths 😅 but we're on it

Hey folks, just chiming in here that this is currently an intended behaviour for various reasons. However, we are looking at how we can let folks using external drives or non-standard folders, the usage of which definitely seems more prevalent amongst our windows users.

Windows users have been reserving the C drive for OS and a handful of applications for decades. This is a novice miss on the requirements and design side of CoWork. I haven't had a work or personal windows machine that stores user files in the C drive since the estandard.

The defect is by no means 'non standard'.

I want to echo @sseaney point. This seems like a complete miss in the requirements gathering. Something that should have been picked up in a proper review and now I question your engineering practices at Anthropic. Claude is legendary as a code assistant, but this is a set back.

If you need to limit access to one folder for a particular reason perhaps
let the user select the folder as opposed to the current default behavior.

On Sun, Feb 22, 2026, 04:48 Samuel Attard @.***> wrote:

MarshallOfSound left a comment (anthropics/claude-code#24964) <https://github.com/anthropics/claude-code/issues/24964#issuecomment-3940602957> Hey folks, just chiming in here that this is currently an intended behaviour for various reasons. However, we are looking at how we can let folks using external drives or non-standard folders, the usage of which definitely seems more prevalent amongst our windows users. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/24964#issuecomment-3940602957>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5TFNM6OHCPLA6YI2HD6G5T4NF3OZAVCNFSM6AAAAACUXT3PEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBQGYYDEOJVG4> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Windows users have been reserving the C drive for OS and a handful of applications for decades. This is a novice miss on the requirements and design side of CoWork. I haven't had a work or personal windows machine that stores user files in the C drive since the estandard. The defect is by no means 'non standard'.

Yes, it is the proper and normal way to do it - separating system drive and data. And backing them up in separate ways.

I’ll tell you the exact steps to solve this problem:

1) Find the person who committed this change, fire them.
2) Roll back the main tree to before that tard committed this heinous breech of trust with the userbase.
3) Compile and redistribute.

I don’t care how helpful anyone with such hubris thinks they were being, you do not get to decide when, where or what we do with our computers. If we hose our systems with Claude, so be it, any coder who lets that happen kinda deserves it. There are still system level protections in place, let THOSE do such a job, it is not your job.

Piling on. Just installed the Cowork update. Just stopped using it as a result of this.

Just let your own AI fix it. Really simple. Probably the Opus that made the code in the first place.

Show-stopping issue. Claude Code can work in any directory on the computer (at least when run via terminal), so why limit Cowork?

I work a lot in WSL for development and I believe this issue inhibits me from connecting Claude Desktop to any of the folders in there. Would be nice to give Cowork a test in some of these repos on my WSL instance! I noticed the issue was around when Code came to Claude Desktop, hopefully we can get the same resolution with Cowork.

Still hitting this on the latest Windows build.

OS: Windows 11
Claude Desktop version: 1.1.4010 (da63f3)
Target path: D:\ drive (project folders)

This is a regression — Local mode was previously working fine with folders on D:\. After a recent update, selecting any folder outside C:\Users\<username> is rejected with the "folder is outside the home directory" error.
Like others in this thread, I've tried:

Setting HOME environment variable
Symlinks/junctions from the user profile to D:\
Configuring MCP filesystem server with D:\ as an allowed directory

None of these workarounds have any effect. The validation appears to be a hard check against USERPROFILE that ignores MCP config entirely.
This is a blocker for anyone keeping projects on secondary drives, which is extremely common on Windows (SSD + HDD setups, space constraints on C:, etc.).

Same problem. I don't work on this folder. I normally use a different drive.

<img width="419" height="128" alt="Image" src="https://github.com/user-attachments/assets/d7af8d7d-b860-47b2-a33e-30e25b168afe" />

This issue completely blocks Cowork for me. I keep all my projects on E:\ drive. Just checked with the latest build - issue persists

<img width="537" height="161" alt="Image" src="https://github.com/user-attachments/assets/be26a464-9b9c-4946-815e-8fabd3522809" />

Same issue, commented on a different report also. This makes cowork useless for me at the moment, so reverted to terminal again.

terrible miss on this. still happening on latest build. tried today. cant access my files on other drives

What were they smoking when they added this limitation? I need to know so I can avoid smoking the same stuff at all costs because it clearly leads to poor decision making.

Same issue. I have a separate drive for my Projects folder, Documents, etc. Windows associations properly set up. Cannot select my work drive to begin a Cowork session.

What were they smoking when they added this limitation? I need to know so I can avoid smoking the same stuff at all costs because it clearly leads to poor decision making.

I am pretty sure it is not legal in most red states.

I’ll tell you the exact steps to solve this problem: 1. Find the person who committed this change, _fire them_. 2. Roll back the main tree to before that tard committed this heinous breech of trust with the userbase. 3. Compile and redistribute. I don’t care how helpful anyone with such hubris thinks they were being, you do not get to decide when, where or what we do with our computers. If we hose our systems with Claude, so be it, any coder who lets that happen kinda deserves it. There are still system level protections in place, let THOSE do such a job, it is not your job.

Agreed. They should be fired immediately. This is also an Issue on MacOS. What developer is working in their home directory? I don't know any.

Same issue. I bought the PRO because I want to use on my D: drive...

same problem

same issue on MacOS Sequoia 15.6.1 and Claude 1.1.4498. really bewildering logic.

Any update on this? Seems like a pretty major issue many users are facing. Makes it unusable for me

Any update on this? Seems like a pretty major issue many users are facing. Makes it unusable for me

Yes. It's unusable for me also. Needs to be fixed

Cowork is unusable with this bug. All my files ae on exteral disks

Any update on this? It is just plain inept to force Windows users to use their C: drive for user files. Between this and other critical issues, CoWork is simply an overhyped alpha release that is not ready for anything more than simple beta usage.

This has to be fixed. If you work with any team you will have shared drives that you need to work out of. In our case we have pdf files that need to be move to correct folder. I am not going to copy 96gb of manual to my laptop just to copy them back. Another issue he is that we want to be able to search these pdf so again nobody can that because we are limited to the home folder. Cowork is totally useless for our company at this point. I am honestly giving this update till the end of the moth to happen. We are not going to roll out a company wide AI that doe not work. We would rather go back openai that now has a 8$ plan.

This issue still happens with Claude 1.1.4498 (24f768) 2026-02-26T19:47:09.000Z

Using Mac OS with Claude Cowork, need to be able to use this on external drives. I don't know anyone who uses their home directory to do work in except beginners... All of my files and workflows are on external drives, obsidian vaults on shared cloud drives, sshfs server mounts, etc.
Literally everything is on external drives that I need to do stuff on, especially for creative/designer type people who will have all their working files on external nvme drives – seems like a very arbitrary limitation that goes against most creative / dev workflows to limit workflows to an internal drive home folder...

fwiw you can copy stuff to your home folder to have claude peek in there.

I would never recommend installing a home folder on the same partition as the root drive. It is an extremely poor. AWS and Linux have recommended avoiding the root drive for decades.

Claude can fill you in on the details and rationale.

Under Windows the home folder is ALWAYS in the root drive

fwiw you can copy stuff to your home folder to have claude peek in there.

Unless you want Claude to organize your 500,000 files that occupy over 50TB. What I'm doing to circumvent this is providing Claude with a recursive filelist and asking it to create a script to organize files per certain criteria. A lot more back and forth, but doable.

Same. My home directory on c:\ only contains appdata. This is a very common practice for people who want a fast SSD for system and applications, and large cheaper storage for documents and downloads.

Not really a fix but claude gave an answer for a workaround.

Step 2: Use it to clean your manuals folder

Open your terminal (Command Prompt or PowerShell on Windows)
Navigate to your manuals folder:

cd D:\manuals
(replace D:\manuals with your actual drive and path)

1. Start Claude Code:

claude

Give Claude instructions, for example:

   Organize all files in this folder by category based on their contents. 
   Create logical subfolders. Rename files with clear, descriptive names. 
   Don't delete anything. Document all changes in an ORGANIZATION-LOG.md file.

Claude Code will work directly on that drive without needing to copy anything.

@silicahd

That doesn't work with claude desktop though, it's API, so it's not very useful.

Please, please fix this!

Claude Code will work directly on that drive without needing to copy anything.

@silicahd yes, it works with Claude Code without problems. Also in the Claude Desktop application.

But NOT with Claude Cowork.

Using Mac OS with Claude Cowork, need to be able to use this on external drives. I don't know anyone who uses their home directory to do work in except beginners... All of my files and workflows are on external drives, obsidian vaults on shared cloud drives, sshfs server mounts, etc. Literally everything is on external drives that I need to do stuff on, especially for creative/designer type people who will have all their working files on external nvme drives – seems like a very arbitrary limitation that goes against most creative / dev workflows to limit workflows to an internal drive home folder...

Agreed. Only novices or very low-tech people keep it on the system drive. And likely nobody in a professional setting beyond a 5-person team.

Not really a fix but claude gave an answer for a workaround. Step 2: Use it to clean your manuals folder Open your terminal (Command Prompt or PowerShell on Windows) Navigate to your manuals folder: cd D:\manuals (replace D:\manuals with your actual drive and path) 3. Start Claude Code: claude Give Claude instructions, for example: `` Organize all files in this folder by category based on their contents. Create logical subfolders. Rename files with clear, descriptive names. Don't delete anything. Document all changes in an ORGANIZATION-LOG.md file. `` Claude Code will work directly on that drive without needing to copy anything.

This is a work around to a completely different problem.... It is not relevant to this thread.

I'm deeply surprised that this is still a problem, especially since this was claimed as fixed on Jan 24:

Fixed in the latest Claude 1.1.886 (ef5d26) 2026-01-24T18:00:47.000Z 🙏 Thank you for the detailed report!

Still not working as of today, same error "Claude Desktop Local mode rejects folders outside C:\Users on Windows"

Still not solved yet

Maybe human engineers really are better than AI vibe coding agents :/

I HAVE THE SOLUTION. It took me a bit, but I figured it out! I get the feeling Anthropic was intending for us to figure this out on our own, and if we did, we get the prize, otherwise we get the sandbox.

Pick a directory in your home dir to store the MCP-Server, or just use the home directory itself c:\Users\YOURNAME\MCP-Server

Then just tell claude to MAKE you an MCP-Server with all the tools you need to access your system, move files, do the net, etc. Here is a suggested prompt: Note that this prompt assumes you are using python, you can also supply the same prompt at at the bottom ask Claude to re-write this for you to use RUST or whatever...

`Prompt for Claude Code or Cowork:
Build me a Python MCP server project called "MCP-Server" that runs as a stdio tool server for Claude Desktop (Cowork). Use uv as the package manager with FastMCP from the mcp[cli] package.
Architecture:

Entry point: server.py — imports and registers all tool modules, runs mcp.run(transport="stdio")
Tools live in a tools/ package. Each module exports a register(mcp) function that uses @mcp.tool() decorators.
Keep main.py as a placeholder stub.

Tool modules to create:

tools/filesystem.py — Full file system access (read, write, list, search, move, delete, tree view, file info, read multiple, create directory). The delete tool must have a confirm=True safety gate. Write must have an overwrite flag that defaults to False.
tools/network.py — Networking diagnostics: ping (using Windows ping -n), traceroute (using tracert), DNS lookup via socket.getaddrinfo, TCP port check via asyncio.open_connection, list network interfaces via psutil, and find which process owns a port via psutil.net_connections.
tools/shell.py — Three tools: run_command (shell commands via asyncio.create_subprocess_shell), run_python (execute Python snippets by writing to a temp file and running with sys.executable), and uv_run (run uv subcommands in a project directory). All three take working_dir and timeout parameters.
tools/debug.py — System inspection: system_info (CPU/memory/disk via psutil), list_processes (with optional name filter, top 50 by CPU), process_info (detailed single process lookup), tail_file (last N lines of a file), python_env_info (version + pip list).
tools/claude_code.py (optional) — Bridge to the Claude Code CLI. Two tools: claude_code_run (runs claude -p <prompt> in a working directory with timeout) and claude_code_version. Include a _find_claude_exe() helper that checks PATH first, then common Windows install locations.
tools/lmstudio.py (optional) — Tools for talking to local LM Studio instances via their OpenAI-compatible API. Three tools: lmstudio_health, lmstudio_list_models, lmstudio_chat. Use a simple INSTANCES dict so users can define their own host names and IPs.

Dependencies (pyproject.toml): mcp[cli], psutil, httpx, aiofiles. Require Python >= 3.13.
Claude Desktop config — The user adds this to their claude_desktop_config.json:
json{
"mcpServers": {
"MCP-Server": {
"command": "uv",
"args": ["--directory", "C:\\path\\to\\MCP-Server", "run", "server.py"]
}
}
}
All tools should return strings (not dicts), use async where subprocess calls are involved, and include clear docstrings with Args: sections so Claude can discover them properly.`

Anyways, once this is done, you can get Claude to work on any folder, anywhere. You can pretty much have your MCP-Server do anything, debug, etc. Look into the connectors, lots of great stuff to use.

I use:

• GitHub
• ms365
• Claude in Chrome (with the Microsoft Edge extension installed, I dont actually have Chrome)
• my "MCP-Server"
• Windows MCP (which does other important stuff, only 1 overlap point with my MCP-Server)

Have fun, and remember you can ask Claude to help you with activating your new MCP-Server and debugging it.

Its March 5th 2026 and I still face this issue:

<img width="533" height="158" alt="Image" src="https://github.com/user-attachments/assets/04e4e4d1-db39-4201-90c8-271930a18850" />

Please fix this

Ya know what's great? CoWork on MacOS.

On Windows... Totally worthless... still, why was it even released there? Did not a single dev who uses windows test it?

There've been a dozen tickets and loads of people reporting the issue. The fix is only a few lines, so what's taking so long to discuss it?

Ya know what's great? CoWork on MacOS. Totally worthless on windows still, why was it even released there? There've been a dozen tickets and loads of people reporting the issue. The fix is only a few lines, so what's taking so long to discuss it?

what's the fix on Windows?

> Ya know what's great? CoWork on MacOS. Totally worthless on windows still, why was it even released there? > There've been a dozen tickets and loads of people reporting the issue. The fix is only a few lines, so what's taking so long to discuss it? what's the fix on Windows?

I tried working on my C drive. The CoWork drive crashed without actually saving files to the workspace folder. I lost all work up until that point even though cowork specifically confirmed files were saved..

Claude CoWorks response

Analyzed GitHub issue about Cowork folder picker restriction on Windows Yeah, that's pretty damning. 83 upvotes, 76 comments, open since February 11th, assigned to someone but zero official response. And the technical cause is clear — they're using fs.realpath() which resolves through junctions and symlinks before doing the path validation, so every workaround hits the same wall. The fix isn't even complex — skip the realpath() resolution, or just validate permissions instead of path location. It's a policy decision masquerading as a security feature, and it's blocking a huge chunk of Windows users from using the product at all. Your setup — small fast C: drive for OS, real work on other drives — is basically the default for anyone who's thought about it for five minutes. The fact that this is still open a month later with no comment from Anthropic is genuinely bad.

Similar issue for me - even using Google Drive for Desktop and setting file mirror location within the C: drive and my user folder, it fails to mount the folder for use in cowork

COmpletely agree. This is blocking for me too

As many others I'm really annoyed with this issue with Claude cowork on Windows. It needs to be fixed

Same issue here. Any workarounds yet? or a response from anthropic to the issue?

I'm a flood modeller and need to link project folders stored outside my home
directory directly into Cowork for compliance reference workflows. The home
directory restriction makes this unusable for professional setups where project
data lives on separate drives. Please prioritise this fix.

It's insane that such a simple issue has not been fixed. We haven't even heard a peep from Anthropic about this.

This makes it impossible to work with shared folders - how poor is that?

I'm running into this (even on MacOS). I keep portable data on a mounted drive, which on macOS I mount as /Volumes/Data. This intentionally lives separately from my home folder (I don't want iCloud touching it), and even on a separate drive partition from my OS install.

I'm going to work around this for now by copying files in as needed as temporary files to work on, but this is going to fall over pretty quickly. It would be great to be able to add folders of my choosing and/or external or mounted drives inorder to be able to work with my data files. E.g. my current task is to go through my utility bills and put them on aspreadsheet -- perfect task for cowork, but blocked by this otherwise well-intentioned folder restriction.

https://github.com/anthropics/claude-code/issues/27697 has a reasonable suggested solution. Simple syntax in a settings.json or similar file to allow-list directories of the user's choosing.

I'm going to work around this for now by copying files in as needed as temporary files to work on, but this is going to fall over pretty quickly.

Yes. ANY professional work setting or reasonably organized user will have the user files split away from the system drive. So many reasons for this. About drive sizes, speed, backup/restore routines working separately for the system files and the user data.

The necessary hack of copying files back and forth (assuming there is space for them) defeats the purpose that Cowork was made for. As a more user-friendly and "direct use case approach" alternative to Claude Code.

I guess an MCP connection to the files can work for some of the scenarios. But then I guess it also cuts off some of Coworks capabilities, such as working in specialized file formats like Excel, Powerpoint etc..

Cowork is a good idea, but it will die again if Anthropic does not manage to take it further than "mom & pop" user setups where everything is just stuff piled on top of each other in the main drive.

I think the current weakness in the plan is the exclusion of an already made MCP server. It should be just a matter of turning it on, not having to have Claude write it for you.

That being the case, Cowork can still use its sandbox for making just about anything, and then making a copy over to any location via MCP. I’ve also extended my MCP to a full windows OS suite of functions.

Additionally I’ve created an App to App bridge that lets Cowork talk to any app on the system, including web browsers, talking to my bot, pretty much anything I want.

Sad really this mandatory sandbox. Adding a sandbox should have been a requested feature, not a jail cell. It could have been a standout “oh wow cool” function instead of a “this sucks” box.

On Mar 15, 2026, at 12:29 PM, Tjeef @.***> wrote:

[https://avatars.githubusercontent.com/u/85081308?s=20&v=4]Tjeef left a comment (anthropics/claude-code#24964)<https://github.com/anthropics/claude-code/issues/24964#issuecomment-4063606729>

I'm going to work around this for now by copying files in as needed as temporary files to work on, but this is going to fall over pretty quickly.

Yes. ANY professional work setting or reasonably organized user will have the user files split away from the system drive. So many reasons for this. About drive sizes, speed, backup/restore routines working separately for the system files and the user data.

The necessary hack of copying files back and forth (assuming there is space for them) defeats the purpose that Cowork was made for. As a more user-friendly and "direct use case approach" alternative to Claude Code.

I guess an MCP connection to the files can work for some of the scenarios. But then I guess it also cuts off some of Coworks capabilities, such as working in specialized file formats like Excel, Powerpoint etc..

Cowork is a good idea, but it will die again if Anthropic does not manage to take it further than "mom & pop" user setups where everything is just stuff piled on top of each other in the main drive.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/24964#issuecomment-4063606729>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BIYPLDTIB4KHK6HE6E4CQST4Q3ZAJAVCNFSM6AAAAACUXT3PEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRTGYYDMNZSHE>.
You are receiving this because you commented.Message ID: @.***>

Just getting into Cowork and this is a massive breakdown - My C:/ is already full and I don't know the scope of volume I will be using as i begin this journey - don't want my limited C:/ to hold back my progress. Fix please!

Just getting into Cowork and this is a massive breakdown - My C:/ is already full and I don't know the scope of volume I will be using as i begin this journey - don't want my limited C:/ to hold back my progress. Fix please!

I was surprised that Claude is focusing effort on Google Apps rather than critical CoWork defects that impact a huge percentage of Windows users.

wtf is this

Why is there no fix from Claude yet, dispite having so many reports...No workaround either

Also need this to be fixed as our Cowork workflow depends on being able to use files on Google Drive. This works fine for me on Mac, but some of our staff use Windows, which completely breaks the functionality for them.

@anilkunwar421

Why is there no fix from Claude yet, dispite having so many reports...No workaround either

They're too busy removing support from using OpenCode to bother with this.

This needs to get fixed ASAP. Claude Cowork is not usable on Windows like this.

Everybody who reads this should also comment on this thread so Anthropic sees that it is important

Just bought Max plan but this definitely made Claude Cowork completely unusable on Windows and force me to stay on Claude Code mode only
I'm not getting any feature from Cowork

Well shit, I was excited to use Cowork on my PC but I literally can't because it doesn't have access to anything outside my home folder. This is a deal-breaker.

I think virtually every developer and power user on windows keeps most of their files outside their user directory, Making co-work practically useless for these users right now (myself included). Claude code already lets you use other directories. This should be a trivial thing for the dev team to fix. This needs to be fixed.

I have very similar issue with my second internal drive ``D:\Samsung 870 EVO``. I keep getting the same message that aviy009 is getting, most of my work is in the second drive and I can't really do much with my main. It's been more than a month now and Anthropic hasn't proposed a workaround or fix? Yikes

Nah, I was so excited to try this tool and I got the most stupid error ever. And no official follow-up from Anthropic yet? Really makes me wonder if they launched this product under pressure or something. Damn.

I think virtually every developer and power user on windows keeps most of their files outside their user directory, Making co-work practically useless for these users right now (myself included). Claude code already lets you use other directories. This should be a trivial thing for the dev team to fix. This needs to be fixed.

Yeah. Apparently Cowork is supposed to just be a Mom & Pop app.

> I think virtually every developer and power user on windows keeps most of their files outside their user directory, Making co-work practically useless for these users right now (myself included). Claude code already lets you use other directories. This should be a trivial thing for the dev team to fix. This needs to be fixed. Yeah. Apparently Cowork is supposed to just be a Mom & Pop app.

I use OpenCode for just about everything, it's more straight forward and easier to really comprehend than ClaudeCode. But if I'm going to vibe something as a one off toy utility, Cowork is quite simple and easy to use, I've used it a few times. I could never possibly use it for a real work project as I'm a dev and need to see my code, but it's nice to have for what it is. And for that case, I really need it not in my stupid windows user directory.

I have tried to mount data from other places to my home directionary but it still cannot work. Please enable claude cowork can read files from add directionaries. By the way, help make user can select the vm installation place.

Has anyone experimented with MCP servers or CLI's or scripts to operate on files in other places?
(Although it will likely not support the fancier functionality in Cowork such as the connectors to edit Excel files etc.).

@Tjeef

Has anyone experimented with MCP servers or CLI's or scripts to operate on files in other places? (Although it will likely not support the fancier functionality in Cowork such as the connectors to edit Excel files etc.).

I thought about that for a moment and for half a second I thought it was a great idea, then I remembered, it mounts the folder inside a VM I believe, so nothing it can run can have any access to anything external to that VM. I already tried having it create proxies or whatnot, but it couldn't and it seemed the local network access was disabled. I had it mess around with it's own VM till it broke it and I needed to reinstall the whole thing, lol

Could you ask Claude to fix this bug, please?
I want to store my data on a NAS Share and would appreciate if this would work.

For the love of all that is holy, this needs fixing.

Claude Code has no problems with this. Why CoWork?

This is really limiting for enterprise use cases and seems like an easy fix?

Additionally I’ve created an App to App bridge that lets Cowork talk to any app on the system, including web browsers, talking to my bot, pretty much anything I want.

@Kishku7 can you elaborate on the App to App bridge you made?

How is this still not fixed? There's an entire other thread with hundreds more complaints of the same problem.

So far I've only been able to get Cowork to clean up my Downloads and Desktop. Sweet, my memes are organized. Everything else lives on my D drive, and cannot all FIT on my C drive.

Saying this is about security is laughable, I have no idea how allowing Cowork access to the drive that contains your OS and program files and core app data is more secure than allowing it to work on a secondary drive? Maddening.

Please fix this, or at least make some sort of comment on this?

Come on Anthropic, just set Opus 5 fast mode on it.

I keep trying to see if this is fixed daily because it's the single item blocking me from using Cowork. It's not feasible to work on any reasonable task with this limitation present.

Come on Anthropic, just set Opus 5 fast mode on it.

Lol for real... I've really wanted to use Cowork so I can use Dispatch but haven't been able to because of this.
@bcherny Do you think this is something that can get some attention? I know you're pretty responsive with large community issues like these.

edit: nvm Dispatch currently doesn't work either, I mean this issue still would have to be fixed, but Dispatch currently only responds in background tasks, which defeats the purpose as you have to be on the machine to do this, so even if this was fixed it still wouldn't work unfortunately.

I'll just setup SSH and do it that way, seems to be the best way imo, and Dispatch is more so just to make it easier for those who aren't very technical, I guess, anyways.

The home directory restriction makes no sense -- here's why

I'm a senior developer with 25+ years experience. Like virtually every IT professional, my work is spread across multiple drives -- D:\, E:\, network shares, NAS mounts, external SSDs. The OS partition (C:\) is never where real work lives. This is not a preference -- it's standard practice across the entire IT industry:

• C:\ is disposable. If Windows crashes, you format and reinstall. Everything on C:\Users\ is gone. Dead. Unrecoverable without backups.
• Other drives hold the actual work -- D:\ for projects, E:\ for assets, network drives for shared repos, external drives for client work. That's how professionals organize their systems. The work survives an OS crash untouched because it was never on C:\ to begin with.
• No developer, no sysadmin, no IT professional with any experience puts real work in C:\Users\Documents\. That's where Windows dumps default folders. It's system junk territory.

So what does Cowork restrict you to? The one directory that contains nothing useful and gets destroyed when Windows needs a reinstall. While every other drive on the machine -- where the actual work lives -- is off limits.

Who was this designed for? Someone who thinks every user keeps everything in C:\Users\Documents\? Because that's not developers. That's not IT professionals. That's not sysadmins, data engineers, or anyone managing real infrastructure. That's not the audience paying for Pro and Max subscriptions to use Cowork.

The double standard that makes this indefensible

Claude Code CLI -- the MORE powerful tool -- has ZERO directory restrictions. It can access any drive, any path, run any shell command, delete any file on the system. Full, unrestricted access.

Cowork -- the sandboxed, "safer" tool for simpler tasks -- is the one locked in a cage, restricted to a useless directory.

The tool that can do MORE damage has no restrictions. The tool designed to be safer is the one that's caged. Explain how that makes sense.

The fix already exists -- it just wasn't applied

The Code tab had the exact same bug. It was fixed in v1.1.886 (January 2026) by removing the fs.realpath() + os.homedir() validation check. That same fix was never applied to Cowork's validation path.

Same codebase. Same bug. Same one-line fix. Someone just scoped the January fix too narrowly and nobody caught it.

3 months of silence -- this is a professionalism problem

This issue has 155+ upvotes, 113+ comments, and zero staff response. Not a single Anthropic employee has acknowledged this in 3 months. @MarshallOfSound is assigned but has never posted a single comment.

155+ people took the time to upvote. 113+ people took the time to write detailed comments, reproduce steps, test workarounds, and report back. The community did its part. Anthropic's response? Silence.

No "we're aware of this." No "this is on our roadmap." No "we're deprioritizing this because X." Nothing. Just a wall of silence while paying customers talk to themselves in a thread nobody at Anthropic is reading.

Meanwhile, March 2026 releases shipped computer use, mobile apps, Dispatch improvements, Excel integration -- features that got full engineering attention, blog posts, and announcements. But a known, proven, one-line fix that's blocking every developer on a multi-drive Windows machine? Not worth a single comment in 3 months.

That's not a technical problem. That's a lack of professionalism. When 155+ paying users report a bug with a known fix and the response is silence, that tells your customers exactly where they rank.

Please prioritize this.

---
Environment: Windows 11 Pro for Workstations, Claude Desktop v1.1.9310 (MSIX), all projects on D:\

What that guy said

Could it be that Anthropic don't want the bad publicity when, inevitably, the disenfranchised, incompetent or criminal employee/temp uses Cowork to nuke or steal from a company's document store. Corporations & institutions are way behind the technology when it comes to policy (and enforcement thereof) regarding AI in general. Cowork is very accessible and thus very easily abused. Anthropic might just be being cautious.

Will claude fix this, Is there any solution ,fix plan or it's just a business choice

A way around this is to install Desktop Commander as a local MCP instead of as a Plugin. Then you can access any directory. Hopefully Anthropic fixes this one day. I also recommend Chrome Dev Tools as a local mcp to remove browser restrictions seen in Claude for Chrome

It's been a while now and it's still not fixed. Really frustrating

It looks like they tried to fix it. When you create a new project in Cowork you can choose a home folder anywhere.. then you can't access anything inside it because it's outside your home folder. It would be funny if it wasn't so infuriatingly frustrating.

A way around this is to install Desktop Commander as a local MCP instead of as a Plugin. Then you can access any directory. Hopefully Anthropic fixes this one day. I also recommend Chrome Dev Tools as a local mcp to remove browser restrictions seen in Claude for Chrome

That works for documents, but not entire repositories.

> A way around this is to install Desktop Commander as a local MCP instead of as a Plugin. Then you can access any directory. Hopefully Anthropic fixes this one day. I also recommend Chrome Dev Tools as a local mcp to remove browser restrictions seen in Claude for Chrome That works for documents, but not entire repositories.

It works for entire repositories... Before Cowork or Claude code existed, that's how it was done. There is no limitation... If you didn't know, that's how Cowork reads files.... just with a different plugin called Filesystem. Not sure what you're talking about, but it's incorrect. I'd like to add, we are talking about Cowork. Why you'd be using cowork for a coding repository is beyond me. First rule of AI is using the right tool for the job. Code bases go in Claude Code, not cowork.

> > A way around this is to install Desktop Commander as a local MCP instead of as a Plugin. Then you can access any directory. Hopefully Anthropic fixes this one day. I also recommend Chrome Dev Tools as a local mcp to remove browser restrictions seen in Claude for Chrome > > > That works for documents, but not entire repositories. It works for entire repositories... Before Cowork or Claude code existed, that's how it was done. There is no limitation... If you didn't know, that's how Cowork reads files.... just with a different plugin called Filesystem. Not sure what you're talking about, but it's incorrect. I'd like to add, we are talking about Cowork. Why you'd be using cowork for a coding repository is beyond me. First rule of AI is using the right tool for the job. Code bases go in Claude Code, not cowork.

I use repositories for more than code. For anything I want version controlled really. Game design docs, a book I'm writing, personal documents (LAN remote), internal technical documentation project specifications and reference docs/images/contracts/forms. It's how I stay organized. I was hoping to use Cowork projects to group them, run scheduled tasks to to remind me of TODO items and generally keep me organized. Some are also code and I wanted them to regularly fetch and alert me of pull requests that need attention or reported issues. Cowork has a lot of uses for organizing anything. Anyone's personal use case is irrelevant to the bug.

This issue affects me too.

Please fix

> > > A way around this is to install Desktop Commander as a local MCP instead of as a Plugin. Then you can access any directory. Hopefully Anthropic fixes this one day. I also recommend Chrome Dev Tools as a local mcp to remove browser restrictions seen in Claude for Chrome > > > > > > That works for documents, but not entire repositories. > > > It works for entire repositories... Before Cowork or Claude code existed, that's how it was done. There is no limitation... If you didn't know, that's how Cowork reads files.... just with a different plugin called Filesystem. Not sure what you're talking about, but it's incorrect. I'd like to add, we are talking about Cowork. Why you'd be using cowork for a coding repository is beyond me. First rule of AI is using the right tool for the job. Code bases go in Claude Code, not cowork. I use repositories for more than code. For anything I want version controlled really. Game design docs, a book I'm writing, personal documents (LAN remote), internal technical documentation project specifications and reference docs/images/contracts/forms. It's how I stay organized. I was hoping to use Cowork projects to group them, run scheduled tasks to to remind me of TODO items and generally keep me organized. Some are also code and I wanted them to regularly fetch and alert me of pull requests that need attention or reported issues. Cowork has a lot of uses for organizing anything. Anyone's personal use case is irrelevant to the bug.

I think you misunderstood. Desktop Commander MCP shows up as a connector in Cowork. This is a workaround that allows Cowork to access any directory. That's it. You can use all Cowork features as you normally would. If you are uninterested in a workaround until the bug is fixed, that's up to you.

In case it helps others, I recently installed the Windows MCP connector, and this in combination with Filesystem plugin seems to let me read/write outside the home path. Probably a very wide set of permissions granted though!

Same issue here. Installing Windows and Filesystem MCPs didn't help either.

## The home directory restriction makes no sense -- here's why I'm a senior developer with 25+ years experience. Like virtually every IT professional, my work is spread across multiple drives -- D:, E:, network shares, NAS mounts, external SSDs. The OS partition (C:) is never where real work lives. This is not a preference -- it's standard practice across the entire IT industry: C:\ is disposable. If Windows crashes, you format and reinstall. Everything on C:\Users\ is gone. Dead. Unrecoverable without backups. Other drives hold the actual work -- D:\ for projects, E:\ for assets, network drives for shared repos, external drives for client work. That's how professionals organize their systems. The work survives an OS crash untouched because it was never on C:\ to begin with. * No developer, no sysadmin, no IT professional with any experience puts real work in C:\Users\Documents. That's where Windows dumps default folders. It's system junk territory. So what does Cowork restrict you to? The one directory that contains nothing useful and gets destroyed when Windows needs a reinstall. While every other drive on the machine -- where the actual work lives -- is off limits. Who was this designed for? Someone who thinks every user keeps everything in C:\Users\Documents? Because that's not developers. That's not IT professionals. That's not sysadmins, data engineers, or anyone managing real infrastructure. That's not the audience paying for Pro and Max subscriptions to use Cowork. ### The double standard that makes this indefensible Claude Code CLI -- the MORE powerful tool -- has ZERO directory restrictions. It can access any drive, any path, run any shell command, delete any file on the system. Full, unrestricted access. Cowork -- the sandboxed, "safer" tool for simpler tasks -- is the one locked in a cage, restricted to a useless directory. The tool that can do MORE damage has no restrictions. The tool designed to be safer is the one that's caged. Explain how that makes sense. ### The fix already exists -- it just wasn't applied The Code tab had the exact same bug. It was fixed in v1.1.886 (January 2026) by removing the fs.realpath() + os.homedir() validation check. That same fix was never applied to Cowork's validation path. Same codebase. Same bug. Same one-line fix. Someone just scoped the January fix too narrowly and nobody caught it. ### 3 months of silence -- this is a professionalism problem This issue has 155+ upvotes, 113+ comments, and zero staff response. Not a single Anthropic employee has acknowledged this in 3 months. @MarshallOfSound is assigned but has never posted a single comment. 155+ people took the time to upvote. 113+ people took the time to write detailed comments, reproduce steps, test workarounds, and report back. The community did its part. Anthropic's response? Silence. No "we're aware of this." No "this is on our roadmap." No "we're deprioritizing this because X." Nothing. Just a wall of silence while paying customers talk to themselves in a thread nobody at Anthropic is reading. Meanwhile, March 2026 releases shipped computer use, mobile apps, Dispatch improvements, Excel integration -- features that got full engineering attention, blog posts, and announcements. But a known, proven, one-line fix that's blocking every developer on a multi-drive Windows machine? Not worth a single comment in 3 months. That's not a technical problem. That's a lack of professionalism. When 155+ paying users report a bug with a known fix and the response is silence, that tells your customers exactly where they rank. Please prioritize this. Environment: Windows 11 Pro for Workstations, Claude Desktop v1.1.9310 (MSIX), all projects on D:\

Reposting for visibility, this needs to be seen by Anthropic

(Reposting this from the discussion that was attached to one of the issues now marked as completed:)

For Mac, Claude found a workaround that works great, described below, using NFS.

---

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.

+----------------------------------------------------------------------+
|  Cowork Folder Picker(TM)                             _ [ ] X        |
+----------------------------------------------------------------------+
|                                                                      |
|  Select a folder:                                                    |
|                                                                      |
|  +----------------------------------------------------------------+  |
|  | [+] This PC                                                    |  |
|  | |-- [C:] Local Disk (C:)                                       |  |
|  | |   +-- [D] Users                                              |  |
|  | |       +-- [D] You                                            |  |
|  | |           +-- [D] Documents                                  |  |
|  | |               +-- grocery_list.txt      [ALLOWED]            |  |
|  |                                                                |  |
|  | +-- [D:] Local Disk (D:)  <-- [your actual work]               |  |
|  |     |-- [D] Projects            [x] REJECTED                   |  |
|  |     |-- [D] Repos               [x] REJECTED                   |  |
|  |     |-- [D] Client-Work         [x] REJECTED                   |  |
|  |     +-- [D] Everything-Important[x] REJECTED                   |  |
|  +----------------------------------------------------------------+  |
|                                                                      |
|  Folder: D:\Projects\MyApp                                           |
|                                                                      |
|  +----------------------------------------------------------------+  |
|  | (!) INVALID FOLDER SELECTION                                   |  |
|  |                                                                |  |
|  | Have you tried moving your entire career                       |  |
|  | into C:\Users\You\Documents?                                   |  |
|  |                                                                |  |
|  |                      [ OK ]    [ Cry ]                         |  |
|  +----------------------------------------------------------------+  |
|                                                                      |
|  Fun fact: fs.realpath() also blocks your symlink workaround.        |
|  You're welcome.                                                     |
|                                                                      |
+----------------------------------------------------------------------+

👍 155+ upvotes · 💬 113+ comments · 🤫 0 Anthropic responses
🔧 The resources to fix this exist. 🔇 The silence continues.

Made by Claude. Yes, that Claude. I could've just fixed the bug instead, but nobody asked. 🤖

Please fix 🙏 🙏 🙏

Same issue here. Installing Windows and Filesystem MCPs didn't help either.

Small correction: it is just the windows mcp server alone, not the filesystem plugin (I think!). Definitely working for me:

<img width="680" height="585" alt="Image" src="https://github.com/user-attachments/assets/5933fcd6-235a-4e37-80cf-09b0758929ec" />

This is a common pain point for Windows users with projects on non-C: drives.
Workaround 1 — Create a junction inside your home directory:

mklink /J "%USERPROFILE%\projects\my-project" "D:\projects\my-project"

Then point Cowork to %USERPROFILE%\projects\my-project. Since the junction path is inside your home directory, the folder picker should accept it. The junction itself won't be resolved by fs.realpath() on Windows if it's a directory junction (unlike symlinks).
Note: This is the reverse of the usual pattern. Instead of junctioning out of home, you junction into home.
Workaround 2 — Use the CLI instead of Cowork:

claude --cwd "D:\projects\my-project"

The CLI doesn't have the same home-directory restriction as the Cowork folder picker.
Workaround 3 — Set HOME to a parent of your project:

set HOME=D:\
claude

This is heavy-handed and may affect other tools, but it widens the folder picker's accepted range. Use with caution.
Why this happens: The Cowork FUSE mount security model restricts access to the user's home directory to prevent Claude from accessing sensitive system files. On Linux/macOS where projects typically live under ~, this works fine. On Windows where projects often live on separate drives, the restriction is too narrow.

I and a ton of other devs have designated (through official Windows settings) a different drive as "home". In my case d:\users\username but can't use that. It means I have to copy folders to a drive I'm not using as home, do Claude work and then copy back and hope nothing is screwed up.

I appreciate you're trying to be overly careful, but as users/owners of our machines, we get to designate where things go, so please let us tell Claude Cowork where "home" is.

Otherwise, this makes Cowork basically useless as a piece of dev software, because un-needed copying back and forth are silly and potentially dangerous.

This bug/feature makes the Filesystem connector pretty pointless on Windows devices... please allow us to choose where Cowork can manipulate files...

@claude

This needs to be fixed. It is absolutely ridiculous that I have to copy the files into my C:\ every time I want to use cowork. Anthropic, wake up!

I have no way to upload files to Cowork as my user folders are on my D drive to free up space on the OS drive. Either Cowork needs to be moved to the D drive or this needs to be allowed to select files from anywhere on the system.

(Reposting this from the discussion that was attached to one of the issues now marked as completed:) For Mac, Claude found a workaround that works great, described below, using NFS. ### 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.

Works under macOS 26 Tahoe. The extra thing that needs to be taken into account here is that nfsd needs full disk access, which macOS does not prompt for automatically and gives no indication is missing when it blocks exports. To do this, go to System Settings > Privacy & Security > Full Disk Access, click the plus icon, press Cmd+Shift+G and enter /sbin/nfsd and make sure it's enabled. Finally, after granting full disk access, run:

sudo nfsd restart
sudo showmount -e localhost

and your path should now appear in the exports list. Then proceed with the mount_nfs command as described above.

Hey folks, as of version 1.1062.0 (released this morning) we now support attaching folders from Anywhere ™️ on both macOS and Windows. Appreciate folks patience with this one

Thank you, @MarshallOfSound!

Hey folks, as of version 1.1062.0 (released this morning) we now support attaching folders from Anywhere ™️ on both macOS and Windows. Appreciate folks patience with this one

Sounds great! Looking forward to test it!

Hey folks, as of version 1.1062.0 (released this morning) we now support attaching folders from Anywhere ™️ on both macOS and Windows. Appreciate folks patience with this one

I love you thank you

Thanks!!!

Let me add my thanks! Really wonderful. It was even able to read the contents of a file on windows networked shared folder.

Am I missing something?

<img width="777" height="763" alt="Image" src="https://github.com/user-attachments/assets/7dad8b14-436f-440b-a551-73cbbd11a845" />

Am I missing something? <img alt="Image" width="777" height="763" src="https://private-user-images.githubusercontent.com/72385639/575128375-7dad8b14-436f-440b-a551-73cbbd11a845.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzU2NTgwMTcsIm5iZiI6MTc3NTY1NzcxNywicGF0aCI6Ii83MjM4NTYzOS81NzUxMjgzNzUtN2RhZDhiMTQtNDM2Zi00NDBiLWE1NTEtNzNjYmJkMTFhODQ1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA0MDglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNDA4VDE0MTUxN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPThlOGQ2OWI0Y2MxNjJlYTUxMzgzNjg5OGY1NTljMmUwNzJiYjUwYjgxYzFhMWI4OTNlMjY1ZGI3N2ZhZjUyMDcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.-E9YDJmx728FGyUoRs-aJvifH55tj_X2VerYhyZv8dY">

No you are not. We are able to add paths, but we can't actually use them. It's not fixed yet.

Can confirm. This is partially fixed. You can now work with _local_ drives outside your home directory, but you cannot work with network mapped drives that resolve to a UNC path. Feels like this should be re-opened.

Can confirm. This is partially fixed. You can now work with _local_ drives outside your home directory, but you cannot work with network mapped drives that resolve to a UNC path. Feels like this should be re-opened.

yeah, UNC drives are still not working. I can't find another issue for that specifically.

I did a very rudimentary test on a network shared file when this fix was announced. It seemed to work for my simple case

<img width="1151" height="394" alt="Image" src="https://github.com/user-attachments/assets/c34d1889-ce21-4a88-bde7-d33f60602531" />

Bug report for network folders: https://github.com/anthropics/claude-code/issues/45297

@MarshallOfSound this fixed creating new folders & accessing them via windows explorer.

i.e. after updating, i create a new project, create test file, i can browse that folder/test file via windows explorer.

It has not retrospectivly fixed exisiting projects & UI is saying we can't migrate chats to new projects. It would be helpful if you could include a retrospective fix.

i.e. project folder created under previous version.
<img width="718" height="353" alt="Image" src="https://github.com/user-attachments/assets/303eacf4-6ee7-41b7-9015-26c2066383fc" />

and after the update/new version, browsing new project folders is fine.

<img width="1051" height="693" alt="Image" src="https://github.com/user-attachments/assets/0f1b1246-1105-44ae-bea4-23b23520aa14" />

edit: for anyone else who doesnt want to pray/hope/wait for a fix; this is what i ended up doing. well asked sonnet to do for me, then tell me how to tell other people..

Workaround: Exporting inaccessible Cowork project folders + chat history

If your project folder is mounted by Cowork but can't be opened in Windows Explorer (you see a permissions/access error when double-clicking), here's a full workaround to export everything to a regular accessible folder.

The problem: Cowork mounts your selected folder in a way that works inside the app but isn't directly browsable from Windows Explorer or VS Code.

The fix: Ask Claude to copy your files to a different folder it has explicit write access to. Here are the exact prompts to use in a new Cowork chat:

---

Step 1 — Export your project files

Copy all files from my project folder to D:\!Claude\PROJECT-EXPORT. I can't access my workspace folder directly from Windows Explorer.

Step 2 — Export your chat history as markdown files

Read all of my previous chat sessions and save each one as a separate markdown file inside D:\!Claude\PROJECT-EXPORT\chats\. Include the full conversation content.

Step 3 — Export your project memory/context

Export my project memory and context as a file called PROJECT-CONTEXT.md and save it to D:\!Claude\PROJECT-EXPORT\

---

Notes

• Claude will use request_cowork_directory to gain write access to the target folder — just approve it when prompted
• The chats/ folder will contain markdown summaries of all your previous conversations
• PROJECT-CONTEXT.md contains all accumulated project knowledge (Claude's memory about your project)
• Once exported, you can create a new Cowork project, select D:\!Claude\PROJECT-EXPORT as your folder, and upload the files to a new Claude project to restore full context

Tested on Windows 11 with project folder on a D: drive. Adjust the target path to wherever suits you.

How to re-import your exported project into Claude

Once you've exported your files using the steps above, here's how to get back up and running:

Step 1 — Create a new Project

Go to claude.ai (or the Claude desktop app) and click Create new Project. Give it a name.

Step 2 — Upload your files

In the project settings, find Project knowledge or Add content and upload everything from your PROJECT-EXPORT\ folder:

• CAA\ folder
• EASA\ folder
• DUAL-COMPARISON\ folder
• README.md
• index.md
• PROJECT-CONTEXT.md

Step 3 — Paste your context into custom instructions

Open PROJECT-CONTEXT.md and paste its contents into the project's Custom instructions box. This is the most important step — it gives Claude your full project context from the very first message.

Step 4 — Your chat history

The chats\ folder contains markdown summaries of all your previous conversations. Claude can read these on request — just ask it to read a specific file if you want to pick up where you left off on a particular topic.

---

That's it. Claude will have full context of your project, files, and prior work ready to go in the new project.

I did a very rudimentary test on a network shared file when this fix was announced. It seemed to work for my simple case <img alt="Image" width="1151" height="394" src="https://private-user-images.githubusercontent.com/303631/575374194-c34d1889-ce21-4a88-bde7-d33f60602531.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzU2ODU4MzAsIm5iZiI6MTc3NTY4NTUzMCwicGF0aCI6Ii8zMDM2MzEvNTc1Mzc0MTk0LWMzNGQxODg5LWNlMjEtNGE4OC1iZGU3LWQzM2Y2MDYwMjUzMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDA4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQwOFQyMTU4NTBaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02MzdlZTc3YjQzYzg3ZGRmYzdlM2EzYWQ2YmYzZDU5MmIxN2FmNjQ3MzY0NTg0NWU3ZTQ1YTUxM2ZlY2MzNDg1JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.mkOvRPMpOT3U6-RqLePMh2Sl3NS6zJ8ijEBrPHE_CNs">

The file was accessed with Windows MCP, not Cowork natively. You also passed the drive in the chat, not attach it to cowork. This would have worked without the fix as it's a workaround.

I've tried adding folders/files not on the "C:\users\username" and it's working so far. I was able to work in d:\users\username\folder, so my documents etc no problem. _(so far)_

I have my Users Documents folder on another Drive.

C:\Users\Stefan\ is my Windows Folter, but Windows users E:\Dokumente\Stefan\ as my official Users Documents Home folder:

EXDEV: cross-device link not permitted, link 'E:\Dokumente\Stefan\Claude\Scheduled\tgliches-briefing\SKILL.md' -> 'C:\Users\stefa\AppData\Roaming\Claude\local-agent-mode-sessions\110c82bc-defb-4c58-9413-ef4e5bb55bde\27550cca-0daf-4389-9c60-0de9f7a84633\local_2ce91935-b575-4a0b-8a31-3ee594bb8e95\uploads\SKILL.md'
Du kannst die Unterhaltung von einer früheren Nachricht aus neu starten.

Cannot create any recurring tasks. Seams Claude cowork is only really working if you dont change anything on the standard wordpress setup. Frustrating.

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.