Cowork scheduled task ("Routine") fires on schedule but takes hours to actually execute — matches known closed issue #36131

### 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 recurring Cowork scheduled task (Routine) reliably records a fired_at timestamp close to its cron schedule, but the actual session takes anywhere from ~7 minutes to over 3 hours to finish, with no visible activity or logging in between. This closely matches a previously reported, closed issue: anthropics/claude-code#36131 ("Cowork scheduled tasks don't fire unless Cowork view is actively focused"), which was closed as "not planned" with no acknowledgment or workaround. I'm filing this as a fresh, better-documented occurrence with two consecutive days of hard timestamp evidence, since the underlying behavior appears unresolved and is causing real confusion for a production use case.

**Environment**
Product: Claude (Cowork), scheduled task / Routine (Claude Code Remote MCP)
Task: a daily cron Routine (0 6 * * * UTC) that refreshes application data into a Cloudflare D1 database and is read by a live website
Trigger ID: trig_016VeT1Sq5fuVVsrtjNvbRHo
Observed behavior (two consecutive days)

**Day 1 (Sep 2, 2026):**

Scheduled: 06:00 UTC
fired_at: 09:38:27 UTC (~3h38m after schedule)
finished_at: 09:45:34 UTC
Actual run duration once started: ~7 minutes
→ Symptom: long delay before the session appears to start; fast once it does.

Day 2 (Sep 3, 2026):

Scheduled: 06:00 UTC
fired_at: 06:23:17 UTC (on schedule, only 23 min late)
finished_at: 09:32:44 UTC
Actual run duration: ~3h09m
→ Symptom: dispatched on time, but the session itself took over 3 hours to complete a task that, per Day 1, should take single-digit minutes.

Both runs eventually succeeded and wrote valid data — this is not a task-logic bug, it's specifically about when/how long it takes for the dispatched session to actually execute.

Why this matters

The account owner (who does not otherwise interact with this scheduled task) reasonably concluded the tracker "only updates once I open Claude," because the real data write appeared to land whenever they happened to check the app, rather than at a predictable time after the stated schedule. Separately, we found and already fixed a self-inflicted issue on our end where the task's own lastRefreshed output field was recording the nominal schedule time instead of the true completion time, which compounded the confusion — but the underlying dispatch/execution-time variance (7 min vs. 3h09m for the same task) is not something we can diagnose or fix from within the session; there is no tool or log available to a session that shows queue time vs. active compute time for its own scheduled dispatch.

Related issue

anthropics/claude-code#36131 — same symptom class (task fires late / takes long to actually run, seemingly tied to whether the Cowork view has been opened), closed as "not planned," no fix or workaround given. This report adds a second, independently observed instance with precise before/after timestamps across two consecutive days, plus a production scenario (a live site backed by scheduled data refresh) where the impact is user-visible and was initially mistaken for the tracker being broken.

Request

Please reopen or link this occurrence to #36131, and if there is a known cause (e.g. scheduled sessions only being dispatched/resumed when the account has an active client connection), it would help to document that explicitly for scheduled-task users, since "runs independently of the app being open" is the implied premise of the feature.

### What Should Happen?

The scheduled task should fire and fully execute at its scheduled cron time (0 6 * * * UTC), completing within a consistent, predictable duration — comparable to the ~7 minutes it takes when it does run promptly — regardless of whether the Cowork app is open or the account has an active session. A scheduled/recurring task's entire premise is that it runs unattended; it should not require the user to open the app or focus the Cowork view before the dispatched session actually executes, and its fired_at-to-finished_at duration shouldn't vary by 25x (7 minutes vs. 3+ hours) for the same task with no error or retry indicated.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. In Claude (Cowork), create a recurring scheduled task (Routine) with a daily cron
schedule, e.g. `0 6 * * *` (UTC), that performs any non-trivial multi-step work
(ours does research + a database write; a simple task may not reproduce this).

2. Let the schedule run for at least 2 consecutive days WITHOUT manually opening or
focusing the Cowork app/view around the scheduled time.

3. Each day, check the Routine's run record for `fired_at`, `finished_at`, and
`status` (via `list_triggers` if using Claude Code Remote, or the task's run
history in the Cowork UI).

4. Compare `fired_at` to the cron schedule time, and compare the
`finished_at - fired_at` duration across the two days.

5. Separately note what time you actually opened/focused the Cowork app that day,
if at all.

Observed (our two consecutive runs):

Day 1 (Sep 2, 2026) — scheduled 06:00 UTC
fired_at: 2026-09-02T09:38:27Z (~3h38m after schedule)
finished_at: 2026-09-02T09:45:34Z
duration: ~7 minutes once actually running

Day 2 (Sep 3, 2026) — scheduled 06:00 UTC
fired_at: 2026-09-03T06:23:17Z (on schedule, ~23m late)
finished_at: 2026-09-03T09:32:44Z
duration: ~3h09m

Expected: fired_at should be within a few minutes of the cron schedule, and
duration should be consistent run to run (comparable to the ~7-minute case) —
not vary by ~25x with no error, retry, or logged cause. Neither run's duration
correlated with a deterministic input (same task, same data volume); the only
external variable we could correlate was roughly when the account's Cowork app
was next opened, matching the pattern already reported in #36131.

Trigger ID: trig_016VeT1Sq5fuVVsrtjNvbRHo (cron: 0 6 * * * UTC)

### Claude Model

None

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

N/A

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

_No response_

Start from the scheduled task/Routine execution path and any run history exposed by list_triggers or the Cowork UI; the report gives Trigger ID trig_016VeT1Sq5fuVVsrtjNvbRHo and expected cron 0 6 * * * UTC. Compare fired_at, finished_at, status, and whether the Cowork app was focused. Done means scheduled runs start near the cron time and complete consistently without requiring the app to be opened, or the limitation is explicitly documented.

Escrito por el modelo de indexación a partir del texto del issue.