[BUG] Cowork: agent-created scheduled tasks can never be device-bound, and "Require this computer" cannot be enabled afterwards

Status Open
Maintainer reply None cached
Activity 2 comments · opened Sep 5, 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?

Surface: Claude Cowork. Cloud-routed Cowork session linked to a macOS desktop (Claude Desktop). Scheduled tasks created through the Claude Code Remote MCP create_trigger tool.

An agent cannot produce a scheduled task that runs on the user's computer, and there is no repair path. Three findings, all reproduced today:

1. create_trigger silently produces a cloud-only task.

Calling create_trigger with requires_local_device: true succeeds, but the response ends with:

not bound: no_signed_approval — this task will run in the cloud only

The task is created and enabled. It is simply never bound to the device. Nothing in the API surface offers a way to complete the binding.

2. The requirement cannot be added afterwards.

Opening that task in the Claude Desktop app, the "Require this computer (Claude Desktop (macOS))" toggle is disabled, with the tooltip:

To require this computer, create a new scheduled task.

So the only fix is for the user to recreate the task by hand in the app. Delete-and-recreate through the API does not help — the binding does not exist on that path at all.

3. "Requires this computer" and "Only on this computer" appear to be different states.

A task the user created in the app with the toggle enabled shows a grey Requires this computer (Claude Desktop (macOS)) badge. Tasks that demonstrably run locally show an orange Only on this computer badge. The UI gives no indication of whether these are the same binding in two display states or two genuinely different states, which makes it impossible to confirm from the task list whether a task will actually run locally.

Why this is worse than an inconvenience

The failure is silent. An agent-created task that needs the device looks installed, appears in the task list, and fires on schedule — but cannot reach:

  • the Cowork desktop scheduled-task list
  • folders on the user's computer
  • Claude in Chrome

So it produces a plausible-looking but wrong result rather than failing.

Concrete case. We tried to build a scheduled task that exports a login's own scheduled-task list to version control, so task coverage is auditable. A cloud-routed run of it saw 2 tasks via list_triggers, while the desktop app showed at least 6, several tagged "Only on this computer". The run reported this honestly, but a less careful prompt would have committed the 2-task list as though it were complete.

Related gap: no tool in any Cowork session lists scheduled tasks held by the desktop app. list_triggers returns only tasks created through the remote API. Combined with the above, an agent can neither create a device-bound task nor enumerate the ones that exist, so scheduled-task coverage cannot be audited programmatically at all.

Possibly related existing issues (none of which cover this): #90154, #91604, #91565.

What Should Happen?

Any one of these would resolve it, in order of preference:

  1. create_trigger can create a device-bound task, with a user approval step if one is needed — the same way other device permissions are approved.
  1. "Require this computer" can be enabled on an existing task, so an agent-created task is repairable rather than disposable.
  1. Failing both, create_trigger should reject requires_local_device: true outright with a clear error, rather than creating a cloud-only task and reporting the problem in a trailing line. A loud failure at creation is much better than a task that looks installed and quietly never does its job.

Separately: a tool that lists the scheduled tasks held by the desktop app, so coverage can be verified programmatically.

The badge distinction should also be made explicit in the UI — if Requires this computer and Only on this computer are different states, the difference should be visible and documented; if they are the same, they should display identically.

Error Messages/Logs

Response from create_trigger with requires_local_device: true
(task IS created, enabled, and scheduled — this line is the only indication of the problem):

  not bound: no_signed_approval — this task will run in the cloud only

Tooltip on the disabled "Require this computer (Claude Desktop (macOS))" toggle
when editing an existing scheduled task in the Claude Desktop app:

  To require this computer, create a new scheduled task.

Toggle help text shown next to it:

  Only runs while your computer is awake. Gives Claude access to the folders
  you've allowed on this computer and to Claude in Chrome.

Steps to Reproduce

Reproduced on macOS with the Claude Desktop app and a cloud-routed Cowork session linked to that computer.

A. Agent-created task is never bound

  1. From a Cowork session linked to a desktop, call the Claude Code Remote MCP tool create_trigger with:
  • name: any
  • prompt: any
  • cron_expression: any (or run_once_at)
  • requires_local_device: true
  1. Read the tool response. The trigger object comes back created and enabled: true, derived_state.folders_state is FOLDERS_STATE_NONE, and the response ends with:

not bound: no_signed_approval — this task will run in the cloud only

  1. No approval prompt appears anywhere — not in the conversation, not on the desktop.
  2. The task will now run in the cloud forever.

B. The requirement cannot be added afterwards

  1. Open the Claude Desktop app, go to the scheduled task list, open that task's edit dialog.
  2. Find "Require this computer (Claude Desktop (macOS))".
  3. The toggle is off and disabled. Hovering shows: "To require this computer, create a new scheduled task."
  4. There is no other way to bind it. Deleting and recreating via create_trigger reproduces step 2.

C. The two badges differ

  1. In the app, create a new scheduled task by hand with "Require this computer" enabled.
  2. Compare its badge in the task list with a task that runs locally: the new one shows a grey Requires this computer (Claude Desktop (macOS)), while locally-running tasks show an orange Only on this computer.

What we were actually trying to do, which is where this surfaced: build a scheduled task that reads its own login's scheduled-task list and commits it to version control, so task coverage is auditable. That task must run on the computer to see the desktop-held tasks. An agent cannot create it, and cannot enable the requirement on the one it created.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A — this is Claude Cowork in the Claude Desktop app (macOS), not the Claude Code CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Not a CLI issue — the template's Claude Code version / terminal fields do not apply; this is Cowork in the Claude Desktop app on macOS. Suggested labels: area:cowork, area:routines, platform:macos.

Not known to be a regression — this is the first time we tried to have an agent create a device-bound task, so we have no earlier working version to compare against.

The severity here is that the failure is silent rather than that it is blocked. A task created this way appears in the list, is enabled, and fires on schedule — it simply cannot reach anything on the computer, so it returns an incomplete result that looks like a complete one. In our case a run reported seeing 2 scheduled tasks when the app showed at least 6.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗