[BUG] Scheduled Cowork task lastRunAt advances without a session actually executing

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 23, 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?

On a daily scheduled task (not a one-off): two of my recurring Cowork tasks — daily-desk-gather and signal-movers-to-pipeline, both cronExpression: "45 6 * * *" (daily 6:45am ET) — showed lastRunAt: 2026-07-23T11:02:57Z in list_scheduled_tasks (i.e., the scheduler recorded a run at ~7:02am ET today), but no new session actually executed:

  • Neither task produced its expected output file for today (desk_gather_2026-07-23.md / 20260723-signal-movers.md — both absent; every prior weekday back to 7/18 has one).
  • I pulled up both tasks' most recent sessions directly (via session transcript inspection) and confirmed they're identical to yesterday's (2026-07-22) completed runs — same content, same numbers, sitting idle. No new turn ran today.
  • Two other tasks in the same pipeline (daily-newsletter-triage-v2, daily-podcast-brief) did run today, but 4+ hours late (completing ~10:41–10:42am ET against a 6:12am/6:30am schedule) — separately worth noting as a timing/reliability issue even where the task does eventually fire.

So lastRunAt is not a reliable signal that a task actually executed — it can advance with no corresponding session. This matches the "doesn't fire unless the Cowork view is actively focused" theory: I don't have the desktop app open/focused most mornings, which is exactly when these are scheduled to run.

Platform: macOS, Claude Desktop 1.24012.1 (0adcae), built 2026-07-21T20:59:53.000Z. Would be happy to share the exact task IDs/session IDs if useful for debugging.

What Should Happen?

A scheduled task's lastRunAt should only advance when a session actually spawns and runs the task's SKILL.md. If a run is skipped or deferred for any reason (e.g., the desktop app wasn't open), lastRunAt shouldn't update — right now it does, which makes it impossible to tell a completed run from a silently skipped one without manually inspecting session transcripts and output files.

Error Messages/Logs

None shown — write "No error surfaced anywhere; the failure is silent. list_scheduled_tasks reports success (a fresh lastRunAt) with no corresponding session or output."

Steps to Reproduce

Create a recurring Cowork scheduled task with a daily cron trigger (e.g. 45 6 *).
Leave Claude Desktop closed or unfocused through the scheduled trigger time.
Later, call list_scheduled_tasks — lastRunAt has advanced to a timestamp at/after the trigger time.
Inspect the task's actual output (an expected file write, or its session transcript via list_sessions/read_transcript) — no new work occurred; the most recent session is identical to the prior day's completed run.
Compare to a task whose trigger happens to land while the app is open — that one updates both lastRunAt and produces real output.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

daily output was produced through 2026-07-22

Claude Code Version

N/A — using Claude Desktop (Cowork), version 1.24012.1 (0adcae), built 2026-07-21T20:59:53Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Likely related to #36131 (same "doesn't fire unless Cowork view is focused" family), but that issue doesn't include direct evidence that lastRunAt itself advances with no session. Happy to share exact task IDs and session IDs on request. Desktop build 1.24012.1 (0adcae), 2026-07-21T20:59:53Z, landed the evening before this specific failure — flagging as a possible timing correlation, not a confirmed cause.

View original on GitHub ↗