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:
- 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 nomcp__scheduled-tasks__*tools. Notably, my scheduled task sessions themselves still calllist_scheduled_taskssuccessfully, so the MCP still exists on the desktop side; interactive sessions just no longer get it. - 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." - 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
- On macOS, have local (folder-bound) scheduled tasks in the desktop app, created originally by Cowork sessions via the
mcp__scheduled-tasks__*MCP. - 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).
- 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. - 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." - 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.
- 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_
3 Comments
Confirming another instance of this on the desktop-control side of the same regression.
I run a local scheduled task (Mon/Wed/Fri) that joins a recurring Zoom meeting, records audio, and transcribes it. It relies on the built-in "Control your Mac" osascript tool to launch Chrome and run local shell scripts. This worked for months.
Since the remote-sessions change, my scheduled runs fail on the first step: mcp__Control_your_Mac__osascript is not available in the run, and a ToolSearch for it returns nothing even on retry. The task itself is still registered and fires on schedule — it just can't reach any local desktop control, because the session now executes remotely and only has the file bridge.
So beyond the management gap described here, the remote-execution change also removes desktop-control tools (osascript / local Chrome) from scheduled runs, which breaks any task that automates local apps. Same root cause; would be fixed by the same kind of device-capability proxying.
Environment: macOS, Claude desktop app (Cowork), scheduled task originally created via mcp__scheduled-tasks__*.
Companion symptom on the same class of bug. My scheduled tasks CAN fire (they run daily/weekly on schedule), but the fired session lacks the MCP tools needed to do the actual work:
No mcp__dispatch__start_code_task → can't spawn Code tasks to run repo work
No Desktop Commander → can't read repo files at their canonical paths
No Apple Notes MCP → can't update note-based drift trackers
No SendUserMessage → can't ping the user with results
The fired session only has Fastmail, Gmail, Shopify, Zoom Docs, and Chrome/computer-use — none of which substitute.
Concrete impact: vinylink-morning-drift-check has failed 13 straight runs since the ~2026-07-07 remote-sessions change. The failure is silent from the user's perspective unless they check task logs — the task marks completed but produced no useful work.
Root cause looks the same as OP's: the remote-executing session gets a tool profile that doesn't match what the user's interactive/scheduled-task environment historically had. The scheduled-tasks MCP not being proxied is one aspect; the broader Dispatch/Desktop Commander/Apple Notes MCPs also missing from scheduled sessions is the other side.
Companion ask beyond OP's proposed fixes:
Give scheduled task sessions the same MCP toolset as interactive sessions on the same machine (the historical behavior).
Or expose an environment flag/config so users can declare "this scheduled task needs Dispatch + Desktop Commander" at task creation time.
Fail loudly on missing tool, not silently: if a scheduled task session can't reach a required MCP, the task run should error out visibly (email/push notification) rather than complete with a stub output.
----
Not at all written by Dispatch Claude.... 👀
I have this same issue. Prior to getting access to "Cloud" tasks any Cowork chat would create local scheduled tasks. Now it seems impossible to have Claude in any way manage or create them which is very annoying and completely breaks my use case. This is a regression no question about it, and it should get fixed at some point unless you're going to get rid of it or make it so cloud instances can use locally hosted browsers via the Claude plugin. I need it to query local tools in my local browser, I'm not exposing those tools to the public internet.