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

Same issue here

Here is what I did:

@jill-diniz

Confirming on macOS, with a workaround that unblocked it for me.

Same error, same reserved Scheduled path, desktop 1.25927.0.

Check this first: Settings → Cowork → Cowork files. If that path is the folder
you're trying to mount (or an ancestor of it), this is your cause.

What worked: Change that setting to a folder outside your working tree. I moved mine
from ~/Documents/Claude to ~/CoworkFiles. ~/Documents/Claude then mounted on the
first attempt with no other change.

This also explains why your Scheduled folder doesn't exist. The check appears to be
path arithmetic against the configured Cowork files location, not a filesystem test — so
creating, deleting, or moving actual folders has no effect on it. Only changing the
setting does.

The catch: it relocates the problem rather than solving it. The new location now holds
Scheduled/, so it inherits the same block. Tested directly:

| Requested | Result |
|---|---|
| ~/CoworkFiles | refused |
| ~/CoworkFiles/Artifacts — a subfolder that isn't Scheduled | refused |

There is no folder that can be both the Cowork files location and mountable. So pick a
location structurally unrelated to your work — a sibling, never a parent or child of it.

One warning: "Change location" copies, it doesn't move. Everything is duplicated
into the new folder and the originals stay behind. Check what's in there first — mine
included a git repo.

Suggested fix, which would also close #54859: exclude the reserved subtree from the
overlap check rather than rejecting the whole parent, or store the scheduled-task data
outside the user-selectable tree. Rejecting a parent because of a child that may not exist
blocks the most common layout there is — one working folder with everything under it.

Confirming this is not an isolated case — I'm hitting the exact same block, with a few additional data points that might help narrow it down:

• Setup: my Cowork files location (Settings → Cowork → Cowork files) points to /Documents/Claude, which is a symlink into /Library/Mobile Documents/iCloud~md~obsidian/Documents/Claude (an Obsidian vault, ~4000+ files across many subfolders). Trying to connect that folder — or any folder above it — as a whole fails with a message that the app data folder can't be shared, consistent with what's described here.
• Not scoped to one execution path: I hit this both when trying to connect the folder for a cloud/remote Cowork session, and when trying to add it as a connected folder for a task explicitly set to run locally ("On your computer") on the same Mac. Same block, same message, both times.
• No folder named Scheduled exists at the point of failure — same as reported here, the reservation appears to be computed/assumed rather than checked against the actual filesystem.
• Version: Claude Desktop 1.15200.0, still reproducible on the current 1.26832.0 (2026-08-06) — the changelog for that release doesn't mention anything related, so this has been open across at least two months of releases.

Practical impact: this makes "one connected folder, full context" unworkable for a real second-brain-style vault. My workaround has been to individually connect ~9 top-level subfolders instead of the vault root, and to duplicate my root-level project-instructions file (CLAUDE.md) into one of those subfolders, since anything sitting directly in the root — including that file — becomes unreachable once the whole folder can't be connected. That works, but it's fragile (easy to forget a subfolder) and defeats the point of a single project-level instructions file.

Would also support the ask in #57177 for a configurable Cowork base path — that seems like the cleanest actual fix, since it would let the app's own data live somewhere that never overlaps with a user's working folder in the first place. Happy to share more repro details if useful.

Hitting the same block, and it looks like this isn't limited to the "empty/phantom folder" case @jill-diniz described.

My setup: /Users/daan/Claude is my Cowork workspace root, holding CLAUDE.md, MEMORY.md, and a Scheduled subfolder. Unlike the original report, my Scheduled folder is real, has lived at that path for months, and is actively used — I have real scheduled tasks stored there. So this isn't only a phantom-path validation bug; it also blocks the legitimate, intended use of that folder.

Error (identical form):

Directory "/Users/daan/Claude" overlaps a protected host location (/Users/daan/Claude/Scheduled) and cannot be mounted.

Confirmed it's not picker-specific: I got the identical error both passing the exact path explicitly and via the native folder picker — same result either way.

Timeline: Worked normally yesterday. Broke without any change on my end — no folder restructuring, no new scheduled tasks, nothing. Only difference between yesterday and today is the app itself (auto-update running in the background is my best guess, though I haven't been able to confirm a version bump).

Why this matters beyond the original report: even for users who are actually using the scheduling feature as intended, there's currently no way to keep working from a root folder that also holds shared context files (CLAUDE.md/MEMORY.md) once it contains Scheduled. Since the scheduled-tasks storage path is hardcoded and not user-configurable (#54859), and each task stores an absolute path internally, moving Scheduled out of the root isn't a safe workaround — it risks breaking existing scheduled tasks. So right now there's no supported way back to the previous working setup other than restructuring a workflow that was fine until this regression landed.

+1 on the ask in the original report: either don't block a parent folder over a Scheduled subfolder (treat it as excluded/read-only internally instead), or ship the configurable storage location from #54859 so Scheduled can live outside the mounted root.

Corroborating with a second failure mode not yet documented here: silent mid-session mount degradation — plus confirmation of the loud mode, on a machine where the Scheduled folder genuinely exists with live tasks.

Environment: macOS 26.5.2, Claude Desktop Claude 1.28929.0, Cowork, local sessions.

Setup: unlike the OP, my scheduled tasks really do live under the folder being mounted — ~/Claude-Work/Scheduled/<task>/SKILL.md — and ~/Claude-Work has been the shared root that every one of my Cowork projects connects for shared credentials (.secrets/), templates, and cross-project instructions. This pattern worked for months across many projects, then broke after an app update with no changes on my end.

Two distinct failure modes observed across different projects:

1. Loud (matches OP): requesting the ~/Claude-Work root fails with the same "overlaps a protected host location (.../Claude-Work/Scheduled)" error.
2. Silent (the dangerous one): in another project's session, the root mount was present and readable at session start, then degraded mid-session with zero surfaced error — directory listings went from full contents, to a single surviving subfolder, to empty, over the course of one session. Tool calls just see an empty or missing tree; nothing tells the model or the user the mount died. The session initially diagnosed it as missing files and worked around it. In unattended/scheduled contexts this is much worse: one of my scheduled automations stalled for multiple nights before anyone noticed, because there was no error to notice.

Cross-reference to #73852: consistent with that report, while the stale root mount was dying mid-session, an explicit new request for a subfolder (~/Claude-Work/.secrets, a sibling of Scheduled/) mounted instantly and worked perfectly in the same session.

Impact: every project pointed at a shared root that contains the Scheduled storage silently lost access to shared credentials/config. Because the failure can be silent, projects degrade quietly until something downstream breaks — which is how it presented for me: discovered only when a session went looking for credentials that had "vanished."

Workaround in use: request subfolders individually (siblings of Scheduled/ mount cleanly); never request the containing root. Echoing #54859 — making the Scheduled storage location configurable, or excluding the reserved path from mount validation when it's empty or the scheduling feature is unused, would resolve this whole class.

Another macOS case, with the cause narrowed down. My Scheduled directory does exist on disk, which lets me test a few things the original report could not.

Environment

• Claude for Mac 1.28929.0 (d1a6bc), build timestamp 2026-08-11T18:58:06Z
• macOS Tahoe 26.6.1 (25G76), MacBook Air 15-inch M4 2025
• Cowork, Opus

Broke immediately after updating to 1.28929.0, on quit and relaunch. The build timestamp above is the same evening it broke. No file changes on my end. The app reports it is up to date, so there is no newer build to move to.

Setup

Project folder is /Users/<user>/Documents/Claude Cowork Projects/Eden Work Life. It contains a real, populated Scheduled/ directory at its root, holding 16 scheduled-task definitions at Scheduled/<task-id>/SKILL.md.

The block is ancestor-based on a real directory

| Requested mount | Scheduled/ at or under it? | Result |
|---|---|---|
| .../Eden Work Life (project root) | yes, at the root | BLOCKED |
| .../Claude Cowork Projects (parent) | yes, one level down | BLOCKED |
| .../Eden Work Life/context (child) | no | MOUNTS FINE |

Directory "/Users/<user>/Documents/Claude Cowork Projects/Eden Work Life" overlaps a protected host location (/Users/<user>/Documents/Claude Cowork Projects/Eden Work Life/Scheduled) and cannot be mounted. Request a project or document folder instead.

Directory "/Users/<user>/Documents/Claude Cowork Projects" overlaps a protected host location (/Users/<user>/Documents/Claude Cowork Projects/Eden Work Life/Scheduled) and cannot be mounted. Request a project or document folder instead.

The child mounting normally is the useful data point. If the validator computed <selected>/Scheduled from the request alone, context would have been rejected too for overlapping context/Scheduled. It was not. So the check is not a blanket per-request pattern. What separates a blocked path from a working one is whether a Scheduled directory actually sits at or under it.

The block follows the folder, not the project

I created a second Cowork project with zero scheduled tasks of its own and pointed it at the same folder. Still blocked, byte-identical error, same cited path.

So this is not a per-project registration. Any project pointed at that folder is refused, whether or not it owns the tasks that created the directory. Creating a fresh project is not a workaround.

This may reconcile with the original report in this issue. ~/Documents/Claude/Scheduled is the documented default storage location (#54859), so selecting ~/Documents/Claude would overlap the default path even with no tasks ever created. Given the original reporter verified the directory was absent from disk and was still blocked, it is worth confirming whether the check consults a device-level list of scheduled-task paths rather than doing a filesystem lookup.

It fails silently

There is no error at session start. The Context panel still lists the folder with all nine of its subfolders, the Working folder panel is simply empty, and the session runs with no file access. Confirmed from inside the session: the sandbox sees only outputs, uploads, and the read-only plugin and skill mounts. No project folder at all.

The error text above only appears if a mount is explicitly requested mid-session. Anything depending on a root-level CLAUDE.md fails quietly with no indication why.

Impact

Scheduled tasks and a mountable project root are mutually exclusive on this build. Creating your first scheduled task in a project makes that project's folder, and every folder above it, permanently unmountable. Only subfolders with no Scheduled/ beneath them can be attached, and only ad hoc, per session.

Untested leads

Moving content down one level into <project folder>/workspace/ and pointing the project at workspace/ should mount, since no Scheduled/ would sit beneath it. Root instruction files move too, so CLAUDE.md becomes workspace/CLAUDE.md. I cannot test it without a working mount. The risk is that creating a scheduled task from that project creates workspace/Scheduled and re-breaks it.

The decisive test is to move or rename the Scheduled/ directory and retry. I have not run it because all 16 of my tasks reference absolute paths into that directory.

Suggested fix

1. Mount the parent with the reserved subfolder excluded, rather than rejecting the whole parent. It is a single known child.
2. Store scheduled-task definitions outside the user-selected tree, per #54859.
3. If a mount is going to be refused, surface it at session start instead of failing silently with the folder still shown as attached.

Confirming this on Windows 11, so the platform:macos label understates the scope. My case adds two things the original report does not cover: the Scheduled folder does exist and does contain tasks, and the failure silently disables every scheduled task in the project.

Paths anonymised. <WS> is the project's connected folder, on a OneDrive-synced drive.

Same error, opposite starting conditions

Directory "<WS>" overlaps a protected host location
(<WS>\05_Claude\Scheduled) and cannot be mounted.
Request a project or document folder instead.

In #71307 the reserved folder does not exist and no task was ever created. In my case it exists, is populated with 16 task definitions, and has been there for weeks. Same refusal. That suggests the check keys off the computed reserved path regardless of whether it exists or is in use.

Refused for every ancestor. Sibling folders that do not contain Scheduled mount normally:

| Requested path | Result |
|---|---|
| <WS> | refused (overlap) |
| <WS>\05_Claude | refused (overlap) |
| parent of <WS> | refused (overlap) |
| <WS>\00_Core | mounts fine |

Regression timeline

| Date | Evidence |
|---|---|
| 2026-07-29 01:05 | A local file on my machine already documents this rule for explicit mount requests. So the overlap check existed then, but only on that path. |
| 2026-07-29 → 2026-08-12 | Every scheduled task in the project runs correctly, daily. The project's configured folder is <WS> and it mounts fine. |
| 2026-08-12 16:49 | App update. Bundled skill files on disk are rewritten (observed via mtime). |
| 2026-08-13 09:29 | First scheduled runs after the update start with no workspace mount at all. |

No configuration was changed in the preceding ten days. Before the update, an explicit request_cowork_directory on <WS> was refused while the configured project mount still worked. After the update both fail. The check appears to have been extended to a code path it previously did not cover, which matches the original reporter's "worked fine for weeks, broke after a restart".

New impact: scheduled tasks fail silently and unattended

Three scheduled tasks dispatched in one batch at 2026-08-13T07:28:31Z:

| Task | Sandbox created | Mounts | Outcome |
|---|---|---|---|
| task-a | 09:29:54 | outputs, uploads only | failed, no workspace access |
| task-b | 09:29:54 | none | failed, no workspace access |
| task-c | 09:41:19 | workspace subfolders | succeeded |

task-c succeeded only because I happened to be at the machine and approved a series of per-subfolder prompts. task-a and task-b never prompted. A scheduled run is unattended by definition, so it cannot answer a permission dialog and cannot recover on its own.

This is worse than a mount refusal because it is invisible. My project has a canary task whose job is to surface failures logged by other scheduled tasks. That canary is itself a scheduled task in the same project, so it failed in the same batch. The failure and the failure reporting share a single point of failure. 16 tasks are affected and nothing in the UI indicated a problem.

Confirming that the "move everything into a subfolder" workaround does not work

I had a migration planned along exactly those lines before reading this issue: move all content into <WS>\workspace and reconnect the project there. The original report's observation, that selecting .../Claude/Workspace produces an error naming .../Claude/Workspace/Scheduled, means the reserved path follows the selection and the workaround only relocates the problem. Saved me a large and pointless file move. Worth flagging prominently for anyone else who lands here.

Minor: enforcement is inconsistent across tools

Within one session:

| Operation | Target | Result |
|---|---|---|
| Read | <WS>\05_Claude\Scheduled\<task-id>\SKILL.md | allowed |
| Grep | <WS>\05_Claude\Scheduled\ | refused, "outside connected folders" |
| request_cowork_directory | <WS>\05_Claude | refused, "protected host location" |
| Read | <WS>\05_Claude\<sibling-file>.md | refused, "outside connected folders" |

Read reaches task definitions inside the protected directory, presumably because list_scheduled_tasks returns their paths, while Grep over the same directory and mounting any ancestor are refused.

Suggested fixes

Seconding #54859: store scheduled-task definitions outside the user's folder, or make the location configurable. A project should always be able to mount its own configured folder.

Failing that, a scheduled run that starts with none of its expected mounts should surface an error to the user rather than proceeding as a normal run.

Environment: Windows 11, Claude Desktop (Cowork), workspace on OneDrive with Files On-Demand, model Opus.

Thanks for the detailed report — the ruled-out list and the path pattern (<selected folder>/Scheduled always being the named conflict) are very useful.

I tried to reproduce this on Claude Code CLI 2.1.233 (Linux), but this check happens in the Claude Desktop app's Cowork folder-mounting layer on macOS before the CLI is involved, so there's nothing I can drive from here — marking it CANNOT_TEST from the CLI side and flagging it for the Cowork/desktop team.

We agree the reported behavior looks wrong: a reserved Scheduled location shouldn't block mounting a parent folder when that folder doesn't exist and scheduling has never been used, and it shouldn't make ~/Documents/Claude itself unmountable.

To help pin down the regression window, could you share:

• the Desktop app version that last worked, if you know it (Settings → About), and whether the app auto-updated around the restart
• whether a folder outside ~/Documents (e.g. under ~/Projects) mounts successfully
• whether creating an empty Scheduled folder there changes the error

🤖 Generated with Claude Code

Second data point, from Windows, plus one difference that matters for the fix.

My data store lives at ...\My-Cowork-Workspace\05_Claude\Scheduled and it does exist, with 16 real scheduled tasks inside. The wording I get is different from yours: "My-Cowork-Workspace can't be added because your Claude data folder is inside it". So the check fires whether or not the reserved folder is on disk.

Timeline here: mounting the root worked until 12 Aug 2026 included and broke on 13 Aug, right after an app update that rewrote the skill bundle files at 16:49 on the 12th. Explicit request_cowork_directory calls had been refusing the root since late July already. The configured project mount kept working until the 13th, so it looks like the check reached that second code path in that update.

Workaround I run on: 10 leaf folders per project. All of them sit in the same OneDrive tree that the root sits in, so OneDrive is not the factor.

On scope, and this is the part I care about: if the fix only covers the case where Scheduled is absent and scheduling was never used, my setup stays blocked. What closes it for me is #54859, letting the data store live outside the mounted tree.

Version data point, in case it helps bound the window: I am on Claude 1.30096.5 (6e1346), built 2026-08-14T21:58:49Z, and the root still refuses to mount. That build is two days newer than my regression and it also brought the persistent "don't ask again" checkbox for desktop folder grants, so the grant dialog got fixed in it while the mount check did not.
The version I was on when it last worked I can't recover, it was whatever shipped before the 12 Aug update.

I'm having this issue on Windows 11. We need it fixed.
Issue showed up after migrating to a new computer. The Claude path was on OneDrive. Now i can't use my OneDrive for Claude anymore.

@bcherny is there a new ticket now that this has been confirmed to be a Claude Desktop issue and not a Claude Code issue. We want to make sure that this issue doesn't get lost between depts. If there is another ticket, please link it here so that all those having this issue can follow it.

Chiming in here after scanning this thread and trying a couple of things with Cowork:

1. Having not changed the Cowork designated work folder path (Customize > Cowork), which was documents/claude/scheduled, I renamed the actual /scheduled/ folder to /claude-scheduled/ and moved it out of the /claude/ parent, up to /documents/
2. As soon as I did that, access was restored to the contents of that folder within cowork. Runs could proceed as they did before June's release.
3. After _that_ I tried to change the designated work folder to this new /documents/claude-scheduled/ and it lost the connection again, same wall hit as before, looking for a "scheduled" subfolder that did not exist.

So... dumb-smart workaround, it seems, is to just let Cowork make its own folder, leave that alone, and mount the _actual_ within the chat window?