[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
Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 4 comments · opened Jul 3, 2026
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] 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:
- Create a new workspace rooted at the folder (the folder becomes the session's root). This works, including for Documents and the OneDrive folder.
- Add the folder to an ongoing session. This fails for the same folders.
Only flow 2 produces the error.
Observed behavior
- 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.
- A whole parent folder is rejected because it contains one protected child.
WindowsPowerShellis 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.
- In at least one case the block fired for a subfolder that was not on disk. For the OneDrive-synced Documents folder,
Get-ChildItem -Forcewas run on the real folder and returned noWindowsPowerShellsubfolder (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)
- #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.
- #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
WindowsPowerShelldoes 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
- Start or open a Cowork session.
- In that ongoing session, add a folder and select the user Documents folder, for example
C:\Users\<user>\Documents. - The add is rejected with the error above.
- 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_
4 Comments
macOS repro — and a variant where
Scheduleddoes exist and is in useHitting this on macOS, so it isn't Windows-only.
Setup:
~/Codehas been my Cowork workspace root for months. It holds all myworking folders and the Cowork-managed
Scheduled/store — 19 scheduledtasks, each at
~/Code/Scheduled/<taskId>/SKILL.md. Worked continuously untiltoday (2026-08-12).
Error when adding
~/Codeto a running session:What makes this variant different from the original report: here
Scheduleddoesn'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_tasksreturning all 19 tasks with correct absolute paths, andthe 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
Scheduledis absent and when it'spresent and working. Either way the parent is rejected.
The consequence is circular: Cowork placed
Scheduled/inside the folder I useas 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
~/Codemount fine(
~/Code/Obsidan Vaultconnected without complaint in the same session), andthe folder still mounts as a new workspace root. Only the
add-to-ongoing-session path rejects it.
Environment:
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.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:
Two differences from the original report that might help narrow this down.
The cited path is
<workspace root>\Scheduledwith no.claudeprefix — 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 noOneDrive - <org>anywhere in my path. So this isn't limited to the managed setup in the environment section.Scheduleddoesn'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 OStoCowork 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.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\Scheduledreturned "Path doesn't exist or isn't accessible." I then created a scheduled task, the tool reported writing it toC:\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 OStoCowork OS Workspaceto 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.
Correction to my last comment — the
Scheduledpath 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.