[BUG] Cowork (Windows): project context folders never mount in new sessions; Add-folder dialog cannot confirm — reproduced on two machines after latest update

Update: the app just auto-updated to 1.20186.0 and the bug persists unchanged.
New sessions still attach zero folders (device reports "connectedFolders": []),
and the Add folder dialog still won't confirm. The Filesystem MCP extension
continues to work against the same directories, so this remains isolated to
the native folder-mount path.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/75625
2. https://github.com/anthropics/claude-code/issues/75403
3. https://github.com/anthropics/claude-code/issues/68954

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

Reproduced independently on another Windows machine (device: ryanciam-pc), Claude Desktop 1.20186.0.

Same regression: a project's context folder shows as connected in the UI, but every new Cowork session starts with get_device_info returning connectedFolders: [], and device_list_dir responds "No folders are connected to Cowork on this device." Only chats that were already open before the update still retain folder access; newly created sessions in the same project never receive the mount. App restart and re-connecting the folder do not fix new sessions.

Started right after the update that also enabled mobile Cowork, matching the timeline and two-machine reproduction reported here. +1 — this is not machine-specific.

Corroborating on Windows with additional diagnostics — same regression (folders show connected, sessions can't read them; Add-folder fails).
Environment

Fails: Windows 10 Pro build 19041, Claude Desktop (had both v1.19367.0 and v1.20186.0.0; cleaned to a single install).
Works only in brand-new projects: Windows 11 build 26200, v1.20186.1.

Findings beyond the original report

The failure survives a complete WSL2 stack. On the Win10 box I enabled CPU virtualization, Virtual Machine Platform, and Windows Subsystem for Linux; installed WSL2 + Ubuntu (wsl --update threw "Catastrophic failure"; wsl --update --web-download succeeded; then wsl --install -d Ubuntu --web-download) and rebooted. Bridge tools (device_list_dir, device_stage_files, device_commit_files) still never register; /mnt/user-data/uploads/ doesn't exist.
"Add folder" fails with "Upload failed due to a network issue" even for a 100 KB folder of 7 files on a local non-OneDrive path (C:). So it's not size, OneDrive, firewall (fails with Defender off), or bandwidth — it's the staging/mount pipeline, with a misleading error string.
Existing projects can't be repaired: re-adding the folder to a pre-July-8 project fails the same way; only newly created projects accept a mount.
A new per-device "sign in again for file-system access" prompt appeared after the update; re-authorizing does not restore access to existing chats/projects — only freshly created ones.

Net impact: projects organized before the update permanently lost file access, forcing recreation and chat migration.

I can confirm I have the same exact issue on the mac as well. Started with the same update. I have also tried multiple fixes to no avail.

The workaround I am using now is to have Claude request access to the project folder at the beginning of a session, even if it's listed in the context box. Make sure you have the exact path. If that doesn't work you can have him request with no path and then you will get a file picker that you can point to the right folder, at least that is how it works on macs.

Update: I believe I discover my issue at least. My cowork project is linked to an online project of the same name. As I understand it the latest update combined cowork and chat, and it was supposed to give you the ability to use the same project but in two surfaces online or cowork. But what also happened when I updated, it created another duplicate project of the same name pinned under my projects on the left hand side. It fact this mirrors what I have online. Thinking at this point they should be the same thing I just randomly unpinned one.

However I think those project folders must still represent one or the other version of the project. One has the original cowork resources and the other has the chat ones. That is not a problem with the online files, but it is with the local one. Long story short I think I was starting chats in the online version of the project without access to the local files even though I selected a cowork chat. I suspect it's like using this online version, as a starting point and then allowing it to request local resources. But it doesn't start with access to the local folder because it was originally built online.

I figured this out because at one point I went in the project folder and saw that there are seemingly two versions of the same project there. So as a test I selected the other version, the one that was no longer pinned and started a chat there. That version which I think is the original project before the update still has local access to the project folder. Now everything works again. Once I figured this out, I changed my online project with the same name to (online). Now I can easily distinguish the two.

So check in your project folder and see if there are two versions of your project. If one version doesn't work try the other one. They will look exactly the same and seemingly point to the same folder. But one has access to the local files because it was the original cowork version, the other doesn't because it was added from online. At least this is my theory.

I suggest we all back up our local projects as they will probably try to merge them as some point and who knows what will happen.

Still reproducing on the latest build — not resolved.
Status to keep this from being auto-closed as a duplicate:

New Cowork sessions still start with connectedFolders: []. Folders show as attached in the project's Context panel, but get_device_info reports none mounted.
Independently reproduced by @Ryankwak0416 on a separate Windows machine, same build.
The Filesystem MCP extension reads and writes the exact same directories without issue — so this is isolated to the native folder-mount layer, not OS permissions or device connectivity.
The Add-folder dialog also won't confirm when the list already contains an entry.

If #75625, #75403, or #68954 share a root cause, glad to have this linked or consolidated — but all of them remain open and unfixed. Please don't close without a fix; this blocks every Cowork workflow that depends on connected folders.
Environment: Windows 11 Pro, Claude desktop v1.20186.0.

TL;DR for maintainers: Since the July 8 update, Cowork on Windows silently detaches any connected folder that contains another connected folder. This kills the common "one top-level workspace, many sub-projects" layout — you can no longer connect the parent. It reproduces on a clean project, isn't caused by symlinks or OS permissions, and still fails on v1.20186.0. The Filesystem MCP extension reads the exact same directories fine, so the defect is isolated to the native folder-mount layer.

-------------------------------------------------------------------------------------------------------------------------------

Root cause (Windows): a connected folder that contains another connected folder is silently detached.
Narrowing this down. On my machine the empty-mount behavior tracks to an overlap-validation rule that appears new in the July 8 update: a folder can't stay connected if it's an ancestor of another connected folder.
Layout that breaks it:

...\Documents\Atlas — connected to Project A
...\Documents\Atlas\Claude\Projects\ADTnow Strategy — connected to Project B
...\Documents\Atlas\Claude\Projects\ADT QA — connected to Project C

Repro:

Create a new project and add the parent folder (...\Documents\Atlas) as its context folder.
Start a session.

Expected: Atlas mounts and the session can read the whole tree.
Actual: Atlas detaches on session start — get_device_info returns connectedFolders: []. Adding it manually mid-session returns: 1 folder was skipped because it overlaps a protected location or is the home/root directory. A non-overlapping sibling folder (e.g. ...\Documents\GitHub) connects and mounts normally in the same session.
So the "protected location" it claims to overlap is one of my own already-connected child folders — not a system path, not home/root.
Ruled out on my end:

Symlinks / junctions — scanned all reparse points under the folder and under %AppData% in both directions. All benign (npm/pnpm workspace junctions, model cache); none cross into a protected location.
Windows privacy / Controlled Folder Access, account config, app restart, PC reboot, logout/login.
Deleting and rebuilding the project — identical result at the add-folder step.

This matches the earlier finding in this thread: the Filesystem MCP extension reads and writes all the same directories without issue, so the failure is isolated to the native Cowork folder-mount layer.
Impact: any nested-project layout is now unusable. A top-level folder that intentionally contains sub-project folders — the "one workspace, many projects" pattern — can no longer be connected at the top level. Still reproducing on v1.20186.0 (Windows 11 Pro).

If the overlap check is intentional, it needs an exception for a user connecting a parent of their own already-connected folders. Silently detaching with no message — or surfacing the misleading "protected location" error — is the core defect.

FOUND IT!!!

Update — root cause is execution mode (cloud vs. local), not nested folders

We've been attributing the folder-drop bug to nested project folders. That's not it.

Retested today with the exact same nested structure (multiple projects mounted under one root — Atlas root plus several nested project folders and a separate GitHub repo folder). Folders stayed connected for the full session with zero drops. Nesting was present the whole time and everything read/wrote fine.

Actual root cause

The variable that matters is where the session runs:

Cloud mode — file access reaches your desktop over a bridge connection between the cloud session and your desktop app. That bridge drops mid-session. When it does, the folder still shows as attached in the Context panel, but the file tools underneath go dead — reads and writes fail even though the card still looks connected. This is the "lost connection" everyone is reporting.
Local mode — the session runs on your own machine and touches the filesystem directly. There is no bridge, so there's nothing to drop. Folders stay connected for the entire session.

Nested folders work fine under local mode, so we can stop chasing the nesting theory. The fix people need is to run locally.

Workaround (works today)

This is a global setting, not a per-session toggle you can flip on the fly.

Open Settings → Cowork.
Find "Run new tasks in the cloud."
Turn it OFF.

When it's on, every new Cowork task starts in the cloud and rides the bridge (which drops mid-session). When it's off, new tasks run locally on your own computer — direct filesystem access, no bridge, folders hold for the whole session.

Two things to know:

This only affects new tasks. A session already started in the cloud stays in the cloud — start a fresh session after flipping the setting for it to take effect.
You can confirm which mode a session is in by the icon: a computer icon means local (good); a cloud icon means it's still running in the cloud.

Why so many people are hitting this at once

The setting ships as cloud-on for a lot of users. They never turned it on — it came that way — so they're all landing in cloud mode by default and hitting the bridge drop without knowing there's a mode to change.

Product ask

The real bug isn't just the drop — it's two things:

The default. New sessions default to cloud, which is generating the support volume. Consider defaulting to local, or prompting the user to choose on first run.
The false-connected state. When the bridge drops, the folder card still shows as attached (false green). It should surface a broken/disconnected state so people know the connection died instead of silently failing reads and writes.

Clean repro to make this airtight

Same nested folders, two runs:

Run in cloud → folders drop mid-session.
Run local → folders hold.

If one other person reproduces that A/B, this moves from "one report" to "reproduced by multiple users."