[BUG] Cowork (macOS): scheduled-task storage root is global and ignores the creating project; its reserved path permanently blocks mounting the containing folder

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?

Cowork writes all scheduled task definitions to a single global root, <root>/Scheduled/, and registers that path as a protected host location. It then refuses to mount any directory containing a protected path, so the folder holding that root can never be mounted.

Directory "/Users/<me>/Library/CloudStorage/OneDrive-<tenant>/10_Knowledge"
overlaps a protected host location
(/Users/<me>/Library/CloudStorage/OneDrive-<tenant>/10_Knowledge/Scheduled)
and cannot be mounted. Request a project or document folder instead.

The registration is permanent. It survives deleting every scheduled task, renaming or removing the directory, disabling all tasks, and restarting the application.

This is related to #71307 but is not the same mechanism, and I think the difference matters. In #71307 the reserved path follows the selected folder, so every candidate parent is refused and no scheduled tasks were ever created. In my case the reservation is pinned to one specific root: a different folder that is actively configured as a Cowork project folder mounts without complaint. #54859 (configurable storage location) would resolve my case.

The decisive finding: the scheduled-task storage root is global and ignores the project that creates the task. I created a task from a project whose folder was ~/Cowork_Projects. It was written to 10_Knowledge/Scheduled/<taskId>/SKILL.md, i.e. into an unrelated folder belonging to a different project. This rules out every user-side workaround, since the root cannot be relocated by moving tasks between projects, and deleting tasks does not release the reservation.

Tests performed

• Test 1. Baseline: tasks present, Scheduled/ present. Refused.
• Test 2. Mount 10_Knowledge/00_Global, a subfolder containing no reserved path. Succeeded.
• Test 3. Scheduled/ renamed away, tasks still present. Refused, and the error still names the now-missing path.
• Test 4. As test 3, after a full application restart. Refused, so this is not an in-memory cache.
• Test 5. All tasks disabled. Refused.
• Test 6. All tasks deleted, Scheduled/ present. Refused.
• Test 7. All tasks deleted and Scheduled/ renamed away. Refused.
• Test 8. Mount 10_Knowledge/Scheduled directly. Refused, so equality is treated as overlap.
• Test 9. Mount ~/Cowork_Projects, a folder actively configured as a Cowork project folder but with no scheduled-task history. Succeeded.
• Test 10. Create a task from the project whose folder is ~/Cowork_Projects. Stored at 10_Knowledge/Scheduled/, not under the creating project's folder.

Tests 9 and 10 together isolate it: being a project folder is not sufficient to trigger the reservation, and task storage ignores the creating project entirely.

Ruled out

• Cloud provider or OneDrive paths: test 2 mounts a subfolder of the same OneDrive tree
• Cloud-only files: the folder is synced for offline use
• Stale sessions predating the folder configuration: new conversations behave identically
• Corrupt project configuration: a project rebuilt from scratch reproduced the failure
• Declined permission prompts: none is raised, the mount is never attempted
• In-memory caching of the reserved path: test 4

Three secondary effects

1. The project-level folder binding fails silently. The Context panel shows the folder as connected, the session receives no mount, and no error is raised in either direction. The assistant reports having no file access while the UI shows access as configured. This presents to the user as the assistant being wrong rather than the app failing, and it cost me several hours before I found the explicit error by requesting the folder manually. Possibly the same underlying refusal as #68954.
2. Scheduled tasks report success while producing nothing. They fire on schedule and lastRunAt updates, but they cannot mount their target workspace so they write nothing. A weekly backup task of mine reported runs for a fortnight while producing no backups. Nothing surfaces the failure.
3. The guard blocks task management. update_scheduled_task documents that a task's current prompt is inspected by reading the path returned by list_scheduled_tasks. That path is inside the protected directory, so the documented way to read a task's own prompt is blocked by the same check.

What Should Happen?

Mounting a directory that contains a Cowork-reserved subdirectory should succeed, with the reserved subdirectory excluded from the mount. Refusing the entire parent is disproportionate, and where the application placed the reserved directory inside a user-nominated folder, it is not avoidable by the user.

Failing that, any of:

• Store scheduled task definitions in application-local state rather than in a user folder
• Make the scheduled-task root configurable (#54859)
• Release the reservation when the last task referencing it is deleted

Separately, and independent of the mount behaviour: the silent failure is the more damaging half. A folder that displays as connected while providing no access should surface an error.

Error Messages/Logs

Directory "/Users/<me>/Library/CloudStorage/OneDrive-<tenant>/10_Knowledge" overlaps a protected host location (/Users/<me>/Library/CloudStorage/OneDrive-<tenant>/10_Knowledge/Scheduled) and cannot be mounted. Request a project or document folder instead.

 
Session mount table with the project's folder configured as `10_Knowledge`, showing no user directory mount at all:
 

/sessions/<id>/mnt/outputs           (rw, fuse)
/sessions/<id>/mnt/uploads           (ro, fuse)
/sessions/<id>/mnt/.auto-memory      (ro, fuse)
/sessions/<id>/mnt/.claude/skills    (ro, fuse)
/sessions/<id>/mnt/.claude/projects  (ro, fuse)

 
Session metadata passed to the assistant reads `User selected a folder: no`, despite a folder being configured on the project.

Steps to Reproduce

1. Create a Cowork project pointed at ~/Workspace.
2. Create any scheduled task. Its definition is written to ~/Workspace/Scheduled/<taskId>/SKILL.md.
3. Request ~/Workspace. The mount is refused as overlapping a protected host location.
4. Delete the task, delete the directory, and restart the application. Repeat step 3: still refused.
5. Create a second project pointed at ~/Elsewhere and create a task from it. Observe that the definition is written to ~/Workspace/Scheduled/, not ~/Elsewhere/Scheduled/.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown build number, but the window is narrow. The workspace mounted normally on the morning of Tuesday 2026-08-11. An app update was installed either that afternoon or on the morning of Wednesday 2026-08-12. The failure was noticed on Thursday 2026-08-13. Current version 1.28929.0 (d1a6bc) is affected. The reserved directory was created 2026-07-10 (stat -f "%SB") and the workspace mounted normally for a month afterwards, so the directory layout did not change and no files were modified on my end. For the avoidance of doubt, this is not the earlier scheduled-tasks cloud-execution change, which landed a week or two before this and which I remediated separately. This is a distinct regression from a later update.

Claude Code Version

Claude for Mac 1.28929.0 (d1a6bc)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Current workaround: mounting individual subfolders that do not contain the reserved path. This restores file access but requires a separate request per subfolder per conversation, prevents cross-folder work in a single session, and is unavailable to scheduled tasks, since a non-interactive run cannot answer a permission prompt.

The affected workspace is a structured knowledge base whose conventions require every Cowork project to mount the workspace root, so that shared context is visible from every project. Twelve projects are affected. Subfolder mounting is not a viable long-term substitute.

Related: #71307 (same error string, reserved path follows the selected folder rather than being pinned to a global root), #54859 (configurable scheduled-task storage location), #68954 (project-level folder not mounted in new conversations).