[BUG] Cowork cloud scheduled task bound to a computer is permanently disabled (suspension_reason=device_absent) after one firing while the computer is asleep, and never auto-resumes

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

A Cowork **cloud** scheduled task created with `requires_local_device: true` is set to `enabled=false` with `suspension_reason=device_absent` the first time it fires while the bound Mac is asleep.

The suspension happens at dispatch, **before any session starts**, so the task's own "is the device reachable?" guard never gets a chance to run and exit quietly. It does **not** resume when the device reconnects, and **no notification is sent**. The task silently stops firing for good after a single missed occurrence.

I lost three days of output before noticing, purely by accident. Re-enabling by hand with `update_trigger(enabled: true)` works and the task runs normally afterwards — until the next miss, when it happens again.

**Environment**

- Claude Desktop (Cowork), macOS, app version 1.49585.0, Apple Silicon
- Task created from a Cowork session via the Claude Code Remote MCP tools (`create_trigger`); `created_via: meta_mcp`
- Task id `trig_01CkjM7FPtbe9R8BtVMjYvks` (an earlier instance of the same task, `trig_01CVWpA4WXHQo5ZQbRtM7aqY`, failed identically)
- `requires_local_device: true`, bound to one device, one connected folder
- Cron `45 0-4,13-23 * * *` — hourly at :45, 06:45–21:45 America/Los_Angeles

**Timeline observed**

| When (PT) | Event |
|---|---|
| Sep 10, 08:45 | First task fires, laptop closed → `device_absent`, disabled |
| Sep 10, ~19:45 | Replacement task fires, laptop closed → `device_absent`, disabled; `next_run_at` freezes |
| Sep 11–13 | No firings at all. Device reachable for hours each day. No notification. |
| Sep 13, 00:04 | Manually re-enabled → runs normally |
| Sep 13→14 overnight | Suspended again, identically |

Note that firing hourly makes this *more* likely to happen, not less: the first miss of the day ends the series.

### What Should Happen?

The missed occurrence is skipped and the recurring schedule is preserved, so the next hourly trigger runs normally once the computer is back.

This is also what the documentation describes. [Schedule recurring tasks in Claude Cowork](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) states that scheduled tasks "run on their cadence even when your computer is asleep." The same page draws the local-vs-remote distinction two sentences earlier without reconciling it, so the documented mental model predicts the opposite of the observed behavior.

For comparison, the equivalent local Desktop scheduled task already behaves correctly — [its docs](https://code.claude.com/docs/en/desktop-scheduled-tasks) say "If your computer sleeps through a scheduled time, the run is skipped", and it does a single catch-up run on wake. Cloud tasks with a device binding should at minimum not be *worse* than that.

If the intent is to avoid dispatching forever to a device that is gone for good, bounded backoff with automatic resumption on device reconnect would serve that — and a notification should be sent whenever a task is suspended. Silent permanent suspension gives the downsides of both options: the task stops, and nothing says so.

### Error Messages/Logs

```shell
list_triggers output for the suspended task (abridged):

{
"id": "trig_01CkjM7FPtbe9R8BtVMjYvks",
"name": "Digest of yesterday's Claude threads",
"cron_expression": "45 0-4,13-23 * * *",
"enabled": false,
"suspension_reason": "device_absent",
"ended_reason": "",
"next_run_at": "2026-09-11T03:45:00Z",
"updated_at": "2026-09-11T02:45:47Z",
"derived_state": {
"folders_state": "FOLDERS_STATE_PRESENT",
"folders": ["/Users//claude-code-logs"]
}
}

next_run_at stays frozen at the missed time and never advances. ended_reason is empty,
so this is a "suspension" rather than a permanent end -- but nothing ever lifts it.

No error is surfaced anywhere: no push notification, no entry in the task's run history
for the suspended occurrences, nothing in the session list. The only visible symptom is
that the task's output stops changing.
```

### Steps to Reproduce

1. From a Cowork session, create a recurring **cloud** scheduled task with `requires_local_device: true` and a connected folder on the bound Mac. Any prompt will do; a one-line prompt that just prints the date is enough to reproduce.
2. Give it a schedule with at least one firing during hours the Mac is normally asleep — e.g. `45 13 * * *` (06:45 America/Los_Angeles).
3. Close the laptop lid (or otherwise let the Mac sleep / the desktop app go offline) and let that firing time pass.
4. Wake the Mac. Confirm the device is reachable — any `mcp__remote-devices__*` call from a Cowork session succeeds.
5. Call `list_triggers` and inspect that task.

**Result:** `enabled: false`, `suspension_reason: "device_absent"`, `next_run_at` frozen at the missed time. Waiting does not help — I left it for three days with the device reachable throughout the working day, and it never resumed. No notification was sent at any point.

**Result expected:** the occurrence is skipped, `enabled` stays true, and `next_run_at` advances to the next slot.

### Claude Model

Opus

### Is this a regression?

No, this never worked

### Last Working Version

_No response_

### Claude Code Version

2.1.268 (Claude Code)

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

**Why this looks like a bug rather than intended policy**

1. `suspension_reason` is documented as a *temporary* hold that lifts when the blocking condition clears — that is how `subscription_paused` behaves. There appears to be no lift path for `device_absent`, even though the platform observably knows when the device reconnects (the `mcp__remote-devices__*` tools appear and disappear in a session as it does). A latch with no release reads as a missing branch rather than a decision.
2. A missed occurrence should not mutate the schedule. Each occurrence should be independent; idempotency belongs in the task's own prompt, not in the scheduler's enabled flag.
3. The behavior contradicts the help centre, which says tasks run on their cadence when the computer is asleep.

**Workaround currently in use**

Two additional scheduled tasks whose only job is to re-enable the first one when `suspension_reason == "device_absent"`: one device-bound (so its `update_trigger` call is pre-approved) and one cloud-only as a backstop for days the device-bound one is itself suspended. Three scheduled tasks to keep one running.

**Related**

#92268 — agent-created Cowork tasks and device binding. Relevant here because it documents that **Require this computer** cannot be enabled on an existing task ("To require this computer, create a new scheduled task"), which is also why the workaround tasks cannot have their approval mode corrected after creation.