[BUG] Cowork: Scheduled reserved-path overlap blocks mounting ~/Documents/Claude and every parent folder — no scheduled tasks ever created

Cross-platform confirmation — same bug on Windows, different folder entirely (not ~/Documents/Claude).

Environment: Windows 11, Claude Desktop (Cowork), project root: C:\Claude_MCP (custom folder, unrelated to Documents).

Same mechanism as described above: mount validation computes a reserved Scheduled subfolder path under the mounted folder and rejects the parent for "overlapping" it — even when that folder does not exist on disk.

Our case is notable because it shows this isn't Documents-specific: it happens for any project root, anywhere on disk. We hit it twice:

1. A folder _OUTPUT\Scheduled did exist at one point (containing unrelated skill-definition markdown files, nothing to do with Cowork's actual scheduling feature). We deleted it entirely on 2026-06-26 (Remove-Item -Recurse -Force, confirmed via Test-Path = False).
2. The identical error — citing the identical, now-nonexistent path C:\Claude_MCP\_OUTPUT\Scheduled — has continued to occur on every mount attempt since, reproducibly, across multiple sessions and days. Re-verified today via Explorer: no folder named Scheduled exists anywhere under the project root.

This matches the reporter's finding above: the check isn't a live filesystem scan, it's a path computed/cached ahead of time and never revalidated against actual disk state.

Would also support the proposed fix referenced here (#54859) — making the reserved-task storage location configurable or moved fully out of any mountable tree.

I am also experiencing this bug on Windows. The project I'm working on is now completely broken, and I can't find a way out of it. I tried changing the working folder to something else, but nothing helps.

Having the same problem on Mac. I can't say for sure that it's since the update, but I did have an update auto install within the last few hours. I hadn't performed any actions that would have revealed the issue before the update, that I'm aware of, but it definitely showed up as soon as I needed to access context from the Claude directory from a session I was working in.

Same here, with the Windows Desktop client. No need to repeat what's already been said, but it is preventing me from configuring Cowork the way I want to, with no clean workaround or fix. Cowork finally told me about this BUG report.

Another data point from a daily Cowork user on macOS (older install whose workspace root is ~/cowork rather than ~/Documents/Claude - the reserved-path check follows whatever the app treats as its base).

Identical behavior: connecting the workspace root fails with the "overlaps a protected host location (<root>/Scheduled)" error even though nothing about Scheduled/ is being touched, so a multi-project workspace that shares top-level context files can only be connected leaf-by-leaf. Our workaround: evacuate every canonical file into a mountable subfolder, keep symlinks at the root for local sessions (cloud sessions cannot follow them), and codify a fixed "connect set" of subfolders that every session and every scheduled task must re-learn. It works, but whole-tree operations stay impossible and the folder list is permanent per-session overhead.

+1 for either #54859 (move Scheduled/ out of the workspace tree, e.g. to ~/Library/Application Support) or #57177 (configurable base path). Either would resolve this class of problem completely.

Same validation bug also applies to ~/.claude, with a different reserved name — and it blocks the global CLAUDE.md.

Requesting ~/.claude from a Cowork session is rejected with:

Directory "/Users/<user>/.claude" overlaps a protected host location (/Users/<user>/.claude/scheduled-tasks) and cannot be mounted. Request a project or document folder instead.

Note the reserved name here is scheduled-tasks, not Scheduled, so there appear to be at least two reserved-path checks exhibiting this behavior.

There's no parent-level workaround either — selecting the home directory is separately refused:

Cannot mount the home directory itself. Choose a subdirectory.

Impact: Cowork cannot read ~/.claude/CLAUDE.md, ~/.claude/settings.json, or ~/.claude/skills/. Asking Claude in Cowork to review or slim your own global CLAUDE.md — a natural request, and one Anthropic's own context-engineering guidance encourages — is impossible. The CLI is unaffected, which makes the inconsistency more confusing.

Expected: exclude the protected subdirectory from the mount rather than rejecting every ancestor of it, or mount ancestors read-only where write access is the actual concern.

Environment: macOS, Claude 1.24012.9 (03c61d) 2026-07-24T04:59:17.000Z, Cowork, model Opus 5.

Same issue for me in Cowork. The exact file and folder I want it to write to it cannot write to.

What workarounds have you found in Cowork? I may need to rewrite everything, but worry that I'd save it in a new folder only to be blocked again.

This is what Claude told me:
<img width="782" height="491" alt="Image" src="https://github.com/user-attachments/assets/a96a8662-657e-4acf-a797-abb49faec60d" />