[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

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:

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.

1. 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.

1. 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)

• #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 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_