[BUG] Scheduled tasks fire but the spawned session never executes - one run reported SUCCEEDED after 12s having done nothing (recurrence of #65537)
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?
Four Cowork scheduled tasks fired on 31 Aug 2026 and produced no effect at all: no files written, no messages sent, no notifications. The same work performed manually in the live interactive session minutes later, on the same machine and the same browser session, completed successfully three times in a row.
This looks like a recurrence of #65537 ("RemoteTrigger routines dispatch but never execute - last_fired_at updates, last_runs stays empty"), which was closed as fixed and is now locked, so I am filing a new issue as the closing notice asks.
Failures (all times UTC)
| # | Schedule | permission_mode | Fired | Outcome |
|---|---|---|---|---|
| 1 | 0 5 * * * | bypassPermissions | 05:16:28.035Z, finished 05:16:40.127Z | Marked SUCCEEDED after 12 s having done nothing |
| 2 | 0 12,18 * * * | auto | due 12:01:10Z | No effect, last_run absent entirely |
| 3 | same trigger, 18:00Z firing | auto | due 18:00Z | No effect, last_run still absent at 18:16Z |
| 4 | one-shot 21:46:00Z | auto | 21:46:13.983Z | last_run.status stuck at PENDING, no effect by 21:50Z |
Test 4 was a deliberately minimal pilot created to isolate the cause. It asked for three trivial steps: read the last message of one chat in a web app, append a row to an .xlsx on the linked machine, then return to the web app and send one line of text.
Control: the same work by hand succeeds
Immediately before test 4, in the live interactive session on the same machine, the identical three-step sequence completed successfully three consecutive times, between 23:24 and 23:34 local time. This rules out: browser closed, tab conflicts, session-takeover prompts, the permission classifier, prompt content, and folder access.
Key contrast
Two reminders created with send_later, which do not spawn a new session but deliver into the already-live interactive session (persist_session: true), fired at 16:30:37Z and 18:16:32Z and both executed correctly. Work delivered into a live session runs. Work that requires the scheduler to spawn a new session does not.
Secondary issues
1) A run that did nothing was reported as SUCCEEDED (test 1). From the outside this is indistinguishable from success, which is the most damaging part operationally. Same false positive as #60658.
2) Two scheduled firings recorded no run at all (tests 2 and 3).
3) The trigger's last_fired_at (05:20:54.518Z) disagrees with last_run.fired_at (05:16:28.035Z) for the same firing.
4) permission_mode is not the cause: one bypassPermissions task and three auto tasks failed identically.
5) permission_mode cannot be changed via update_trigger (only name, cron, enabled, model, prompt), forcing delete-and-recreate and losing the task's run history.
Impact
These tasks drive daily operations for a 30-apartment holiday-rental business: notifying the cleaning team of departure times and sending guests their arrival and departure instructions. All three daily passes had to be redone by hand, and a nightly summary failed to arrive two nights running.
Related: #47899, #56086, #51133, #60658.
What Should Happen?
Each scheduled fire should spawn a session that actually executes the configured prompt, produces tool calls, and writes its output. A run that performed no work should never be reported as SUCCEEDED, and a run that is dispatched should always be recorded. permission_mode should be editable in place via update_trigger so a misconfigured task does not have to be deleted and recreated, losing its run history.
Error Messages/Logs
None. That is part of the bug: no error is surfaced anywhere. Test 1 reports status SUCCEEDED, tests 2 and 3 report no run at all, and test 4 sits at PENDING. The only way to notice the failure is that the expected work simply never happened.Steps to Reproduce
1) Create a scheduled task (trigger) with a simple prompt that writes a file and sends one message, bound to a linked desktop with the browser open and logged in.
2) Wait for it to fire. Confirm via the trigger listing that last_fired_at advanced and a session id was assigned.
3) Observe that nothing the prompt asked for happened: no file written, no message sent, no notification.
4) Check the run status. Depending on the case it will be SUCCEEDED after a few seconds, PENDING indefinitely, or absent entirely.
5) Perform the exact same steps by hand in a live interactive session on the same machine: they succeed every time.
Reproduced four times on 31 Aug 2026 across three different triggers, two different permission modes, and both cron and one-shot schedules.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Cowork desktop app on Windows (exact build not captured; tasks configured with model claude-opus-5)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
The tasks run in a cloud session linked to a Windows desktop, driving the linked machine's files and browser. Trigger ids and session ids for all four failures are available on request; they are omitted here because this is a public issue.
I am happy to leave the failing one-shot pilot in place for inspection, and to re-run it on request.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Corroborating this from a completely different use case (daily news-digest email tasks, not the holiday-rental scenario above) — same root cause, reproduced independently:
Trigger/session IDs if useful for debugging:
trig_01W3oFp5B1j7AZfBnJ8dM2WJ — sessions cse_01Qgpmz6DZDrWus7TSgr18jx, cse_01WTibbQtHyssAtWVgcbeKTz, cse_01VWL7zA4rpcnqPVsSHhyhHV
trig_014md3oQmuqkxrsdyFsphasV — sessions cse_01LANG4FoY4LkDhEGU33wPdS, cse_01GzMa2jbz1RrcV7GSog14CB
trig_013QbncunBBerMcVFy1Ni5ir — session cse_01Hmo4hPskiY8P4XsQozVuTz
This is currently forcing a fallback to a fully external system (Google Alerts + Gmail filters) since scheduled tasks can't be relied on for time-sensitive automated delivery right now.
Confirming @jasonwertheimer-beep's report, and adding a second failure mode that appeared today.
Same setup as my original report: Windows desktop linked to a cloud session, scheduled tasks driving daily operational passes.
What changed on Sept 1. On Aug 31 my tasks either recorded no run at all or hung at PENDING, matching what Jason describes. Today they behave differently - and worse, because they now look successful:
| Task | Scheduled | Actually fired | Status | Duration | Side effects |
|---|---|---|---|---|---|
| A | 07:00 | 07:17 (+17 min) | SUCCEEDED | 8 seconds | none |
| B | 14:00 | 14:25 (+25 min) | SUCCEEDED | 12 seconds | none |
The same work run interactively takes several minutes and completes correctly - I ran both passes by hand afterwards to verify. So
SUCCEEDEDhere means "a session started and exited", not "the work happened". Anything monitoring task status will report green while nothing is being done, which is harder to detect than a hang.Systematic dispatch delay. Four different tasks today fired 17, 25, 22 and 10 minutes late. That includes a one-shot reminder created minutes earlier in the same session, so it is not specific to old or recurring triggers.
Backup chains are also affected. I second Jason's point here, because it is the practical killer: I built a chain of self-scheduled wake-ups to work around the failure, and those wake-ups are hitting the same delays. A retry mechanism built on the same scheduler inherits the same fault. The only workaround that has been 100% reliable for me is a human typing one word into the live session.
Open question that would help narrow this down: are the affected triggers pre-existing ones, or do freshly created triggers fail too? Jason reports that manually firing via
fire_triggeralso hung, which suggests the dispatcher rather than the trigger record. I have a trigger created today from a linked desktop that fires next Monday; I will report back whether it executes, since that isolates "old triggers are corrupt" from "the dispatcher is broken".thx @crsorens-cpu in it togerher!
To help narrow "old trigger corruption" vs. "dispatcher is broken": in my case, a freshly created trigger failed too.
On Aug 31, I created a brand-new one-off test task and fired it manually — completed cleanly in 14 seconds. But my pre-existing recurring task ("Daily ad-holdco news watch") hung at PENDING for 90+ minutes that same morning, minutes apart, same account.
To rule out job size as the differentiator, I then split that task into two smaller newly created triggers and fired them manually. Despite being brand-new, both hung the same way as the old one — 30+ minutes at PENDING, zero side effects.
So: a trivial fresh trigger succeeded, but new triggers doing "real" multi-step work (web search + email) failed identically to the old one they replaced. Points toward the dispatcher struggling with a specific kind of session (longer-running, multi-tool-call, spawned outside a live chat) rather than trigger age — freshness didn't help once the work matched the broken pattern.
I’m seeing a closely related scheduled task failure. My existing tasks still fire, but the spawned run has lost the local workspace it was created against and now shows Working folder: Scratchpad.
The same ~/Cowork workspace is still available normally in regular Cowork sessions, so the task exists and runs, but its execution context is wrong.
I traced the breakpoint to the late August Cowork migration and documented the full repro here: #91604