Cowork sessions can no longer manage local scheduled tasks: scheduled-tasks MCP not exposed to (now remote-executing) desktop sessions, and the Scheduled folder is blocked as a protected location

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?

Companion to #76961 (local scheduler reliability). This one is about a lost management capability.

Summary

I run ~37 local scheduled tasks on the macOS Claude desktop app (Cowork). They were all originally CREATED and amended by Claude itself, in Cowork sessions, via the local scheduled-tasks MCP surface (mcp__scheduled-tasks__create_scheduled_task / update_scheduled_task / list_scheduled_tasks). That workflow is documented all over my operations system and worked for months.

Since the remote-sessions change (~2026-07-07 release), a Cowork session started from the same desktop app executes in a cloud sandbox and reaches the Mac through the remote-devices file bridge. In such a session there is now NO path to manage the local scheduled tasks:

1. The scheduled-tasks MCP is not exposed/proxied. The session's toolset has the device file bridge and the cloud trigger API (claude-code-remote), but no mcp__scheduled-tasks__* tools. Notably, my scheduled task sessions themselves still call list_scheduled_tasks successfully, so the MCP still exists on the desktop side; interactive sessions just no longer get it.
2. The file fallback is blocked. The deployed task stubs live under ~/Documents/Claude/Scheduled/. Trying to connect that folder (or ~/Documents/Claude) to the session fails with "1 folder was skipped because it overlaps a protected location or is the home/root directory."
3. The cloud trigger API only manages cloud triggers, not the local task roster.

Net effect: a re-time of 14 local tasks that Claude prepared end-to-end (canonical bodies, rosters, verification) ends in a hand-written checklist the human must apply task-by-task in the UI. The assistant that built the automation can no longer touch it.

Related composer bug (hit while trying the folder workaround)

When adding a folder to an EXISTING session from the composer, the folder chip appears at the TOP of the message box (like a file attachment, not in the folder area), and the Submit button goes dead with no error shown; the "protected location" dialog only appears in other flows. Removing the chip restores Submit. Restarting the app twice did not change this.

Asks

• Proxy the local scheduled-tasks MCP into (remote-executing) desktop Cowork sessions, the way other device capabilities are bridged; or
• provide an equivalent tool surface for local task management from a session; or
• exempt the app's own Scheduled folder from the protected-location rule for read/write of task stubs (it is the app's own automation surface, and the user explicitly consents via folder-connect).
• Fix the composer folder-chip / dead-Submit state so a refused folder add fails loudly instead of silently disabling Submit.

What Should Happen?

A Cowork session started from the desktop app should be able to list, create, and re-time the user's local scheduled tasks, as it could before the remote-sessions change: either via the scheduled-tasks MCP (proxied like other device capabilities) or via a supported file/API surface. A folder add that is refused should fail with a visible error, not a silently disabled Submit button.

Error Messages/Logs

Steps to Reproduce

1. On macOS, have local (folder-bound) scheduled tasks in the desktop app, created originally by Cowork sessions via the mcp__scheduled-tasks__* MCP.
2. Start a new Cowork session from the desktop app (post remote-sessions release; the session executes in a cloud sandbox with the remote-devices bridge).
3. Ask Claude to re-time or list the local scheduled tasks. Observe: no mcp__scheduled-tasks__* tools exist in the session's toolset (tool search returns nothing); only the cloud trigger API (claude-code-remote) is present, which manages cloud triggers only.
4. Try the file route: connect ~/Documents/Claude (or ~/Documents/Claude/Scheduled) via Add folder. Observe the refusal: "1 folder was skipped because it overlaps a protected location or is the home/root directory."
5. Variant of step 4 from the composer of an existing session: the folder chip appears at the top of the message box like an attachment and the Submit button silently disables; no error dialog is shown until the folder is removed.
6. Result: no programmatic path from the session to the local task roster; schedule changes must be applied by the human in the UI, one task at a time.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude desktop app 1.20186.1 (Cowork; session executing remotely via the device bridge; not the CLI)

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_