[BUG] Cowork: scheduler "protected host location" registration persists server-side

Status Open
Reported on v2.1.209
Maintainer reply None cached
Activity 1 comment · opened Jul 17, 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?

Title:
[BUG] Cowork: scheduler "protected host location" registration persists server-side — survives task deletion, folder deletion, reboot, and full app reinstall; no user remedy exists
Body:
Environment

macOS, Claude desktop app (Cowork research preview)
Working folder: an Obsidian vault in iCloud Drive at ~/Library/Mobile Documents/com~apple~CloudDocs/Documents/Sphere (iCloud "Desktop & Documents Folders" OFF; "Optimise Mac Storage" OFF)
First reported to Anthropic support twice (2026-06-26 with full write-up; 2026-07-02 addendum); no resolution, filing here because the state appears to be server-side and only Anthropic can clear it.

Steps to reproduce

With a folder mounted as the Cowork project folder, create scheduled tasks. Cowork stores them inside the user's content tree at <vault>/conversations/Scheduled/<taskId>/SKILL.md.
Delete every scheduled task via the app UI. Remove the now-empty conversations/Scheduled/ folder. Verify: zero tasks in the registry, folder gone from disk, folder does not regenerate.
Attempt to mount the parent folder (~/Documents, or the vault root ~/Documents/Sphere).

Expected
With no tasks and no scheduler folder on disk, the parent mounts normally.
Actual
Mount refused with:

Directory "…/Documents" overlaps a protected host location (…/Documents/Sphere/conversations/Scheduled) and cannot be mounted.

The cited path does not exist on disk. New sessions show: "1 folder was skipped because it overlaps a protected location or is the home/root directory."
Persistence evidence (the core of this report)
The registration survives, in escalating order:

Deleting all tasks and the scheduler folder.
Reboot.
Brand-new conversations/sessions.
Full app removal (app + associated ~/Library files) and reinstall. The same overlap error returns immediately on a clean install.

Since a clean install reproduces the block, the registration is not client state — it appears to persist server-side against the account. There is no user action, including the nuclear one, that clears it.
Additional finding: the check compares path strings, not real paths
The identical physical folder mounts without complaint via its iCloud path string: ~/Library/Mobile Documents/com~apple~CloudDocs/Documents/Sphere (same directory as ~/Documents/Sphere). So the overlap guard blocks a string that names the folder while permitting the folder itself — the protection is superficial, and the block it imposes is purely a usability penalty.
Impact
Once the scheduler has ever been used inside a folder, that folder's root and every parent become permanently unmountable for the account. In my case ~/Documents — the default home of working files — has been unmountable since June 2026.
Related issues (adjacent, but none document the server-side persistence)

#54859 — scheduler storage hardcoded under ~/Documents (this issue is the downstream consequence)
#57177 — configurable workspace base path
#59302 / #47180 — scheduled-task folder permissions not persisting (same subsystem, opposite failure: my registration over-persists)

Asks

Deregister a protected location automatically when its tasks/folder are deleted.
Provide a user-visible (or at minimum support-invocable) way to view and clear protected-location registrations account-side.
Make the overlap check resolve real paths rather than compare strings.
Root-cause fix per #54859: keep the scheduler's store out of user content folders entirely.

What Should Happen?

With no tasks and no scheduler folder on disk, the parent mounts normally.

Error Messages/Logs

Steps to Reproduce

as above

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.209 Sonnet 5

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗