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

[jwishon]

TL;DR for maintainers: Since the July 8 update, Cowork on Windows silently detaches any connected folder that contains another connected folder. Connected folders "dropping" mid-session is cloud execution mode, not nested folders. Cloud sessions reach the desktop over a bridge that drops; the folder card stays false-green "attached" while file tools silently die. Workaround: Settings → Cowork → "Run new tasks in the cloud" → OFF (global; new tasks only). Root causes to fix: (1) cloud-on default is generating the volume; (2) UI shows "attached" when the bridge is dead — should show a broken state. Nesting and symlinks are ruled out.

---

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Environment

• App: Claude Desktop (Cowork mode), version 1.19367.0 (Electron 42.5.1)
• OS: Windows 11 Pro, both machines
• Plan: Max (20x)
• Started: July 8, 2026, immediately after the desktop app update (the one that also enabled mobile Cowork). Second machine received the same update July 9 and broke within the hour.

Summary

Since the update, Cowork folder mounts are completely broken:

1. Projects still show their context folders in the Context panel, but every new session starts with zero folders actually attached. Claude confirms from inside the session that connectedFolders is empty on the device bridge.
2. Re-adding is impossible: in the Add folder dialog, when the folder list already contains an entry, the confirm action is dead — Enter and the confirm button do nothing. No error is shown.

Steps to reproduce

1. Open an existing Cowork project that has a context folder attached (visible in the Context panel)
2. Start a new session in that project (any first message)
3. Ask Claude to list the connected folder → it reports no folders are connected to the device
4. Click + → Add folder, select the folder → the dialog will not confirm

Expected

New sessions inherit the project's context folders and mount them; Add folder attaches a folder mid-session.

Actual

Sessions start with nothing attached despite the UI showing the folder; Add folder silently refuses to confirm. get_device_info from the session shows "connectedFolders": [] while the project UI shows the folder as attached.

Ruled out (extensive troubleshooting)

• Full app quit (from tray) and relaunch — no change
• Full PC reboot — no change
• Sign out / sign back in — no change (state appears device-local)
• Windows privacy settings: File system access ON, Documents library access ON, per-app access ON
• Windows Controlled folder access: OFF
• Account mix-up: same account everywhere, verified in Settings → Account
• Not machine-specific: reproduced on a second Windows 11 PC, different account, untouched configuration — identical symptoms starting within an hour of that machine receiving the update

Additional diagnostics

• The device bridge itself is healthy: get_device_info responds normally, and the Filesystem MCP extension works perfectly (Claude can list/read/write the same directories through it). Only the native Cowork folder-mount path is broken — this isolates the failure to mount registration/attachment, not device connectivity or OS file permissions.
• Around the same time, unexplained OS-native-looking folder access prompts appeared, and plan usage meters displayed inconsistently (weekly usage showing 94%/100% used, then 0% with a different reset time ~15 minutes later after an app restart).

Possibly related

• Cowork: folder mount unavailable until after first message in a new session #76183 — folder mount unavailable until after first message. May be the same underlying change, but our failure persists after the first message: the Add-folder confirm stays dead mid-session whenever the list already has an entry.

Impact

All project-based Cowork workflows relying on connected folders are unusable. Current workaround is routing all file access through the Filesystem MCP extension, which bypasses native mounts entirely (no staging/commit, no local sandbox shell).

What Should Happen?

New sessions should inherit and mount the project's context folders automatically, and the Add folder dialog should let me confirm a selected folder and attach it mid-session. Both worked exactly this way before the July 8 update.

Error Messages/Logs

Steps to Reproduce

Every new session starts with zero folders attached even though the project's Context panel shows them. The device reports "connectedFolders": [] from inside the session. In the Add folder dialog, when the folder list already contains an entry, Enter and the confirm button do nothing — no error, the folder just never attaches.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

1.19367.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[jwishon]

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.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] [Cowork] New project's local folder context fails to load - mcp__remote-devices__device_list_dir not registered in session #75625
2. [BUG] Cowork (Windows Store app): device bridge authenticates and announces tools, but sessions never receive them — folder connected but unreadable #75403
3. [BUG] Cowork Windows: project-level folder not mounted in new conversations - only surfaces when file access is attempted #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

[Ryankwak0416]

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.

[dsoiaa]

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.

[Bomma72]

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.