[BUG] Cowork: adding a folder to an ongoing session fails with "overlaps a protected host location", but creating a new workspace in the same folder works

[adamfgr]

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?

Summary

On Windows, adding a folder to an already-running Cowork session is rejected with "overlaps a protected host location", while creating a new workspace rooted at the exact same folder succeeds. Since the new-workspace path mounts the same folder successfully, the rejection is specific to the add-to-ongoing-session path. This affects common folders such as Documents and OneDrive-synced Documents, and it reproduces on more than one machine.

Environment

• OS: Windows 11
• Surface: Cowork mode
• Documents redirected into OneDrive via Known Folder Move (org policy), so the Documents known-folder resolves to C:\Users\<user>\OneDrive - <org>\Documents
• Reproduced on two separate machines with the same setup

The two flows

There are two ways to attach a folder to Cowork:

1. Create a new workspace rooted at the folder (the folder becomes the session's root). This works, including for Documents and the OneDrive folder.
2. Add the folder to an ongoing session. This fails for the same folders.

Only flow 2 produces the error.

Observed behavior

1. The rejection is tied to the add-to-ongoing-session path only. The identical folder mounts fine when it is the root of a new workspace, so the folder itself is not the problem.

2. A whole parent folder is rejected because it contains one protected child. WindowsPowerShell is a folder Windows auto-creates under Documents for PowerShell profiles and modules, so the Documents folder becomes unmountable on this path because of one auto-generated subfolder. With Documents redirected into OneDrive, the protected paths sit inside the OneDrive tree, so the top-level folders a user is most likely to pick (Documents, OneDrive Documents, OneDrive root) all get rejected.

3. In at least one case the block fired for a subfolder that was not on disk. For the OneDrive-synced Documents folder, Get-ChildItem -Force was run on the real folder and returned no WindowsPowerShell subfolder (nothing hidden or system either), yet the add was still rejected citing that exact path. This suggests the check is a static path pattern rather than a filesystem lookup.

Impact

Documents and OneDrive-synced Documents are among the most common folders users want to attach. Adding them to a running session is blocked, which forces the user to either start a new workspace or attach a narrower subfolder. In the reported case this blocked a user's actively used OneDrive Documents folder while work was in progress in an existing session.

Related issues (not duplicates)

• [BUG] Cowork: adding a folder to an existing project/task silently fails — "Session VM process not available" (Windows) #50168: same flow (adding a folder to an existing session) but a different symptom, a silent failure with "Session VM process not available" rather than a protected-location rejection.
• Cowork file tools (Write/Edit) blocked on connected-folder paths containing parentheses #61946: a related but different message, "resolves to a protected location or a path outside the connected folder", raised for Write/Edit on connected-folder paths containing parentheses.

Workarounds in use

• Create a new workspace rooted at the folder instead of adding it to an ongoing session.
• Add a narrower subfolder that contains no protected child, for example Documents\Work.
• Renaming or deleting WindowsPowerShell does not reliably help, because Windows regenerates it and the OneDrive-synced case shows the block can fire even when the folder is absent.

What Should Happen?

• The add-to-ongoing-session path should accept any folder that the new-workspace path would accept. The two paths should apply the same rule.
• If a protected subpath is the concern, verify it actually exists on disk before blocking, and mount the parent with that subfolder excluded rather than rejecting the whole parent.

Error Messages/Logs

Tool call input:

{
  "path": "C:\\Users\\<user>\\Documents"
}

Tool call output:

Error
Directory "C:\Users\<user>\Documents" overlaps a protected host location (C:\Users\<user>\Documents\WindowsPowerShell) and cannot be mounted. Request a project or document folder instead.

The same rejection occurs when adding:
- The OneDrive root (C:\Users\<user>\OneDrive - <org>), cited as overlapping .claude\Scheduled.
- The OneDrive-synced Documents folder (C:\Users\<user>\OneDrive - <org>\Documents), cited as overlapping ...\Documents\WindowsPowerShell.

Steps to Reproduce

1. Start or open a Cowork session.
2. In that ongoing session, add a folder and select the user Documents folder, for example C:\Users\<user>\Documents.
3. The add is rejected with the error above.
4. For contrast, create a new workspace rooted at the same folder. This succeeds and the folder mounts normally.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

1.18286.0 (259c3f) (Claude for Windows)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

No response

[jordanwilliamsLT]

macOS repro — and a variant where Scheduled does exist and is in use

Hitting this on macOS, so it isn't Windows-only.

Setup: ~/Code has been my Cowork workspace root for months. It holds all my
working folders and the Cowork-managed Scheduled/ store — 19 scheduled
tasks, each at ~/Code/Scheduled/<taskId>/SKILL.md. Worked continuously until
today (2026-08-12).

Error when adding ~/Code to a running session:

What makes this variant different from the original report: here Scheduled
doesn't exist on disk and no tasks were ever created. In my case it exists, is
populated, and is actively in use — the scheduler is healthy, with
list_scheduled_tasks returning all 19 tasks with correct absolute paths, and
the one enabled cron task having last run 2026-08-09 with the next run set for
2026-08-16. So the block fires both when Scheduled is absent and when it's
present and working. Either way the parent is rejected.

The consequence is circular: Cowork placed Scheduled/ inside the folder I use
as my workspace root, and that generated folder now makes my own root
unmountable. It isn't resolvable from the user side — relocating Scheduled/
would orphan the absolute paths held in the task registry.

Also corroborates #73852: individual children of ~/Code mount fine
(~/Code/Obsidan Vault connected without complaint in the same session), and
the folder still mounts as a new workspace root. Only the
add-to-ongoing-session path rejects it.

Environment:

• macOS 26.6.1 (25G76)
• Claude 1.28929.0 (d1a6bc) 2026-08-11T18:58:06.000Z
• First observed 2026-08-12; the same folder mounted fine the day before

Suggested fix, echoing #73852: verify the protected path actually exists before
blocking, and when it does, mount the parent with that subfolder excluded
rather than rejecting the whole tree. Otherwise any user whose workspace root
contains the Cowork-generated Scheduled/ folder loses their root.

[CindyKee]

I hit this same "overlaps a protected host location" rejection on Windows, but on flow 1 — selecting the folder as a workspace root — not on adding a folder to an ongoing session. So I don't think the rejection is specific to the add-to-ongoing-session path.

I'm on Claude for Windows v1.30096.1 (2026-08-13), Windows 11. The only build after that one is v1.30096.5, and its notes list no user-facing Cowork changes, so this is still present on current.

The folder had been my Cowork workspace root for months. After an update I couldn't select it in the folder picker anymore, and a direct mount request failed the same way:

Directory "C:\Users\<user>\OneDrive\Documents\Cowork OS" overlaps a protected host location (C:\Users\<user>\OneDrive\Documents\Cowork OS\Scheduled) and cannot be mounted. Request a project or document folder instead.

Two differences from the original report that might help narrow this down.

The cited path is <workspace root>\Scheduled with no .claude prefix — the OneDrive root case above cites .claude\Scheduled.

And I'm on personal OneDrive (C:\Users\<user>\OneDrive\Documents), not org Known Folder Move — there's no OneDrive - <org> anywhere in my path. So this isn't limited to the managed setup in the environment section.

Scheduled doesn't exist on disk, and I have no scheduled tasks configured at all, which lines up with point 3 about the check being a static path pattern rather than a filesystem lookup. Quitting fully from the system tray and relaunching didn't clear it either.

What did work: renaming the parent from Cowork OS to Cowork OS Workspace. It mounted immediately with everything intact. So the protected path behaves like a stored literal tied to the old root name rather than something recomputed from whichever root you pick.

[CindyKee]

Following up on my earlier comment — I found what creates the protected path, and it's reproducible.

Cowork stores scheduled tasks at <workspace root>\Scheduled, and that same path is what the mount check treats as a protected host location. So a workspace that has ever had a scheduled task in it ends up blocking its own root from mounting.

Repro:

Mount a folder as a Cowork workspace root.
Create a scheduled task. The task file is written to <workspace root>\Scheduled\<task-id>\SKILL.md.
Try to mount that same workspace root again. It's rejected as overlapping a protected host location at <workspace root>\Scheduled.

I confirmed the ordering today by accident. Before creating any task, requesting ...\Cowork OS\Scheduled returned "Path doesn't exist or isn't accessible." I then created a scheduled task, the tool reported writing it to C:\Users\<user>\OneDrive\Documents\Cowork OS\Scheduled\<task-id>\SKILL.md, and the identical request now returns the protected-location rejection instead.

Worth noting that the storage root doesn't follow a rename. I had renamed my workspace from Cowork OS to Cowork OS Workspace to get it mounting again, but the new task still went to the old Cowork OS\Scheduled path and recreated that folder in Documents.

That last part also explains how the block can fire for a path that isn't on disk — the protected registration outlives the directory it points at.

[CindyKee]

Correction to my last comment — the Scheduled path comes from the configurable "Cowork files: artifacts and scheduled tasks" location in Settings, which I had pointed at my workspace folder, not from the workspace root itself. So the repro needs that setting aimed at a folder you also mount as a workspace; with the default location you probably won't hit this.