[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."

Confirming on Windows 11, Claude Desktop (auto-updated 2026-08-11).

Setup

• Project's primary folder: ...\OneDrive\0.- CLAUDE COWORK\1.- INFRAESTRUCTURA CLAUDE\3.- PROYECTOS COWORK\GESTION DEPORTISTAS
• Context folders: the OneDrive root (an ancestor of the above), plus Downloads.

Symptom
The Context panel still lists the OneDrive root, but it is never mounted in the VM.
Downloads (not an ancestor of anything) mounts fine.

Evidence from inside the VM

• mount shows the project folder, outputs, uploads and the internal shares — the OneDrive

root is not in the mount table at all. Only a bare empty directory at the mount point.

• Host side reports success and does it instantly:

[VM:steps] add_plan9_shares completed (20ms)
So the share was never in the list the host passed to the guest — this is not a guest-side
mount failure.

Additional finding not in the original report
This is not limited to new sessions. A session that had the folder mounted and was actively
using it for hours lost it mid-conversation, with no user action. So already-running
sessions get their folders stripped too, which means "start a new session" is not a
workaround and long-running tasks can break halfway through.

Confirmed workaround
Removing the ancestor folder and connecting sibling folders instead (branches that do not
contain the project folder) mounts correctly and stays mounted.

Severity note: the UI keeps showing the folder as connected while it is detached underneath,
so there is no indication anything is wrong until a file read fails.

Seeing the same symptom on macOS (not just Windows).

Environment:

• OS: macOS (Darwin 25.5.0, Apple Silicon)
• Claude desktop app version: 1.30096.1

Repro:

1. Created a Cowork project, connected a local folder to it in one chat via "Add folder."
2. Started a brand-new chat within the same project.
3. New chat reports "no folder is connected to this session yet" and prompts to add the folder again, even though the project's own settings still show the folder as connected/attached.

Workaround tested: toggling Settings → Cowork → "Run new tasks in the cloud" OFF, per this issue's diagnosis — did NOT fix it on macOS, folder still disconnects on every new chat.

Matches the root cause described above (bridge drops on cloud-executed tasks, UI stays false-green "attached") — confirming this isn't Windows-specific.

Still reproducing on Windows 11 on a much newer build — 1.34493.1 vs 1.19367.0 in the original report.

Environment

• Claude Desktop: 1.34493.1
• Electron 42.9.2 / Node 24.18.1
• Platform: win32 x64 (Windows 11)
• Folder type: cloud-synced (Dropbox), under C:\Users\<user>\Dropbox\
• Observed: 2026-08-21

(Paths below are anonymized; folder-name characteristics that may be relevant to the bug are preserved — see the note at the end.)

What I see

Two folders have been listed under Settings → Cowork → Trusted Cowork folders since I first set up the desktop app:

• C:\Users\<user>\Dropbox\Alpha
• C:\Users\<user>\Dropbox\Alpha Catalog

A new Cowork session starts with only the first of the two mounted. get_device_info returns:

{
  "platform": "win32",
  "arch": "x64",
  "appVersion": "1.34493.1",
  "electronVersion": "42.9.2",
  "nodeVersion": "24.18.1",
  "connectedFolders": [
    "C:\\Users\\<user>\\Dropbox\\Alpha"
  ]
}

device_list_dir on the parent directory confirms the second folder exists on disk and is simply not granted to the session:

{
  "skeleton": true,
  "directories": ["Alpha", "Alpha Catalog", "..."],
  "note": "Names only — this directory is not connected to this session, so file entries and contents are hidden."
}

Possibly relevant: the two folder names

The folder that mounts and the folder that doesn't differ in two ways that seem worth checking:

1. The failing folder's name contains a space (Alpha Catalog).
2. The failing folder's name is a prefix-extension of the one that succeeds (Alpha → Alpha Catalog).

If grant resolution does a prefix match or an unquoted path split anywhere, either would explain why the second entry silently drops out of connectedFolders while the first survives.

No project-context fallback on this build (see also #76694)

The usual suggestion is to attach the folder as project context instead. That path isn't available here: the project Context panel on this build offers no "Choose a folder" / "Add a local folder" option.

<!-- CONFIRM BEFORE POSTING: open your project's Context "+" and replace the list below with exactly what it shows. Delete this comment line. -->

The Context "+" menu offers only: Upload from device, Add text content, GitHub, Drive, Notion.

The net effect on Windows is that there is currently no route to a persistent per-project folder mount — project context won't accept a folder, and trusted-folder entries don't reliably mount into new sessions.

Impact

Every session needs a manual in-session folder grant before any file work can begin. Since nothing surfaces a warning when a trusted folder fails to mount, it's typically discovered only when a read or write fails partway through a task — after work has already been done against the wrong assumption.

Happy to pull logs or test a build if that would help.

A disk-level datapoint I haven't seen in this thread, from Windows 11 Pro on 1.37937.0, so the regression survives past the 1.34493.1 reported above.

After a clean shutdown, no project→folders record appears to be written to disk at all.
Searching the app-data directory for the attached paths, the only places they survive are:

• Local Storage, key cowork-picker-recents — the file picker's recent list
• claude_desktop_config.json → preferences.localAgentModeTrustedFolders
• HTTP and query caches (Cache/, an IndexedDB React-Query blob)

All three are records of something else. spaces.json under the app-data directory does have a per-project folders array, but it has not been modified since March and contains only long-obsolete projects — so it looks like a legacy store the current UI no longer writes.

That may explain why the Context panel and the session disagree: if the panel is rendering from a store that is never persisted, a restart would leave the panel populated from cache while the session has nothing to mount.

Repro is the one already in this thread; the only addition is where to look afterwards.

Still reproducing on Windows 11, Claude Desktop 1.37937.3 (28dcf5, build 2026-08-26) — one patch past the 1.37937.0 report above.

Two things to add: a note that this thread's main workaround no longer exists on current builds, and a datapoint I haven't seen here.

The workaround is gone from the UI

The advice throughout this thread is Settings → Cowork → "Run new tasks in the cloud" → OFF. On 1.37937.3 that setting is not present — the local-vs-cloud execution control is missing from Settings entirely, not relocated anywhere I can find. So anyone arriving here on a current build has no way to apply the fix. If cloud execution is now unconditional, that would also mean the bridge-drop failure mode described above can no longer be avoided by the user at all.

Worth confirming on other current-build machines before treating it as settled.

The failure isn't limited to local folder mounts

The project's own uploaded knowledge fails to deliver too, in the same sync, partially.

The Context panel lists 10 local folders, 2 linked sheets, 1 URL, and three .md knowledge documents. What the session mount actually contains:

.projects/<project-uuid>/
├── docs/            <- EMPTY (panel lists three .md knowledge docs)
├── files/           <- 3 spreadsheets — these DO arrive
├── memory.md        <- arrives
└── metadata.json    <- arrives

Zero of the ten folders. No sheets, no URL. But files/ and memory.md come through fine.

So within a single project sync, some payloads land and others don't. That may narrow things: it isn't a wholesale "sync never ran" failure, and for the .md docs it can't be explained by the device bridge or OS permissions at all, since those are server-side project knowledge with no local mount involved.

The sync fires and delivers nothing

Editing the Context list (added a folder, then removed it) triggers a re-sync — the docs/ directory mtime moved 06:27 → 06:32 — and docs/ was still empty afterward. Pipeline runs, payload doesn't arrive.

This seems to corroborate @vpapaloukas's finding above that the panel renders from a store that is never persisted: the panel keeps displaying entries, the sync keeps firing on edit, and neither results in content reaching the session.

Not #76694 — this project still has the folder menu

Worth distinguishing, since the two get conflated. This is a pre-merge project and its Context + menu still offers "Choose a folder." Adding and removing folders works normally, no dead confirm button. The option is present and functional; it simply has no effect on what the session can reach. So the mount failure is independent of the missing-menu regression in #76694 — fixing that one would not fix this.

Environment

• Claude Desktop 1.37937.3 (28dcf5), 2026-08-26
• Windows 11
• Pre-merge Cowork project, Context panel intact with folder option available
• Model: Opus 5
• Observed 2026-08-27

Happy to pull logs or check specific paths on disk if that would help.

Cowork (Windows): project-assigned local folder disappears from the project
tab after closing/reopening the project; session reports zero connected folders.

Environment

• Device: Windows, x64
• Claude desktop app: 1.49585.0
• Electron: 44.2.0 / Node: 24.20.0
• Date observed: 2026-09-09

Steps to reproduce

1. Create a project in the desktop app.
2. Assign a local folder (Desktop) via the project's folder button.
3. Folder shows as active. Clicking it shows a chat history instead of the

folder's files - no files from the folder are listed.

1. Close the project, reopen it.
2. The folder is gone from the project tab entirely.

Actual result
get_device_info in the Cowork session returns "connectedFolders": []
while the folder had been assigned to the project.

Expected result
The assigned folder persists across project close/reopen and is mounted
in new sessions.

Notes

• Re-adding the folder mid-session works as a workaround.
• Appears related to #76187 (Windows, folders never mount in new sessions)

and #86647 (macOS, UI shows folder while session sees none), both open.