[BUG] Cowork Scheduler Issue
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?
<html>
<body>
<!--StartFragment--><html><head></head><body><h2>Preflight Checklist</h2>
<ul>
<li>[x] I have searched existing issues and this hasn't been reported yet</li>
<li>[x] This is a single bug report (please file separate reports for different bugs)</li>
<li>[x] I am using the latest version of Claude Desktop</li>
</ul>
<hr>
<h2>What's Wrong?</h2>
<p>All scheduled tasks in Cowork stopped executing on <strong>May 27, 2026</strong> and have not run since — despite the desktop app, Chrome, and the Claude in Chrome extension all remaining open and active. A full quit-and-relaunch of the Cowork app on June 10 did not resolve the issue or trigger any catch-up runs.</p>
<hr>
<h2>Environment</h2>
<ul>
<li><strong>Claude Desktop version:</strong> <em>Version 1.11847.5 (9692f0)</em></li>
<li><strong>Windows version:</strong> <em>Windows 11 Home version 25H2, build 26200.8655)</em></li>
<li><strong>Platform:</strong> Windows (desktop Cowork app)</li>
<li><strong>Affected since:</strong> 2026-05-27</li>
<li><strong>Reported:</strong> 2026-06-10</li>
</ul>
<hr>
<h2>Affected Tasks</h2>
<p>All three scheduled tasks are affected regardless of their schedule:</p>
Task ID | Cron | lastRunAt (frozen) | nextRunAt behavior
-- | -- | -- | --
daily-email-digest | 45 5 * (every day, 5:53 AM) | 2026-05-27T09:53:37.603Z | Recalculates to "tomorrow" on every check, never fires
daily-tiller-refresh | 15 5 2-6 (Tue–Sat, 5:15 AM) | 2026-05-27T09:16:31.259Z | Recalculates to "tomorrow" on every check, never fires
monitor-tiller-refresh | 0 6 2-6 (Tue–Sat, 6:02 AM) | 2026-05-27T10:02:38.475Z | Recalculates to "tomorrow" on every check, never fires
<p>Notably, <code>daily-email-digest</code> fires <strong>every single day</strong> and has not run in ~2 weeks — this rules out the issue being specific to one task's cron expression or SKILL.md content.</p>
<hr>
<h2>Key Observations</h2>
<ol>
<li>
<p><strong><code>lastRunAt</code> is frozen at near-identical timestamps for all three tasks</strong>, all within ~46 minutes of each other on 2026-05-27. This strongly suggests a single shared scheduler state/checkpoint got stuck at that moment, rather than three independent failures.</p>
</li>
<li>
<p><strong><code>nextRunAt</code> is computed live</strong> and updates correctly every time <code>list_scheduled_tasks</code> is called — but this appears to be display-only. The underlying trigger mechanism never actually fires.</p>
</li>
<li>
<p><strong>No new sessions are created</strong> for any scheduled task since May 27 (confirmed via <code>list_sessions</code> — the last "Daily tiller refresh," "Daily email digest," and "Monitor tiller refresh" sessions are all dated May 27 or earlier).</p>
</li>
<li>
<p><strong>A full quit-and-relaunch of the Cowork app on 2026-06-10 did not trigger any catch-up runs</strong>, even though the <code>create_scheduled_task</code> documentation states: <em>"Scheduled tasks run while this app is open. If the app is closed when a task is due, it runs on next launch."</em> This suggests either (a) the catch-up mechanism is broken, or (b) the scheduler's persisted state didn't reset on relaunch.</p>
</li>
<li>
<p><strong>Toggling <code>enabled</code> off and back on via <code>update_scheduled_task</code></strong> does not fix it — only recalculates <code>nextRunAt</code>, with no effect on <code>lastRunAt</code> or actual firing.</p>
</li>
<li>
<p><strong>Updating <code>cronExpression</code> via <code>update_scheduled_task</code></strong> also has no effect on the frozen state.</p>
</li>
</ol>
<hr>
<h2>Timeline / What We Ruled Out</h2>
<ul>
<li>
<p><strong>2026-05-27:</strong> A session called <code>update_scheduled_task</code> to update <code>daily-tiller-refresh</code>'s prompt/SKILL.md content. This is the last moment any task successfully ran. It's possible (but unconfirmed) that this update call coincided with or triggered the freeze.</p>
</li>
<li>
<p>The scheduled task SKILL.md files live on a NextCloud-synced <code>D:</code> drive (<code>D:\NextCloud\Documents\Claude\Scheduled</code>), while Cowork's session storage is on <code>C:</code> (<code>C:\Users\kevin\AppData\Roaming\Claude\Scheduled</code>). Hard-linking across drives raises <code>EXDEV: cross-device link not permitted</code> on Windows. A <strong>directory junction</strong> was created to resolve this (<code>D:\NextCloud\Documents\Claude\Scheduled</code> → junction → <code>C:\Users\kevin\AppData\Roaming\Claude\Scheduled</code>). This junction was already in place when checked on 2026-06-10 (created ~2026-05-31), but the scheduler freeze persisted for the 10 days since — so this was not the sole root cause.</p>
</li>
<li>
<p>A Windows Task Scheduler entry ("Launch Cowork (Wake)") wakes the PC and launches Cowork at 5:10 AM, but was only configured for Tuesday–Friday (missing Saturday). This has been corrected to Tue–Sat, but does not explain the <code>daily-email-digest</code> failures (every day, including weekdays).</p>
</li>
</ul>
<hr>
<h2>Questions for the Team</h2>
<ul>
<li>Is there a persisted "last scheduler tick" or similar checkpoint that could get stuck and not advance even across app restarts?</li>
<li>Does the "runs on next launch if missed" catch-up behavior actually exist and function? If so, why didn't relaunching on 2026-06-10 trigger 3 overdue runs?</li>
<li>Could the <code>update_scheduled_task</code> call on 2026-05-27 — which edits a SKILL.md file behind a NextCloud-synced directory junction — have caused a write/lock error that silently corrupted scheduler state for <em>all</em> tasks, not just the one being edited?</li>
<li>Is there a log file or diagnostic the user could retrieve to show what (if anything) the scheduler attempted at 5:15 AM / 5:53 AM / 6:02 AM on any day since May 27?</li>
</ul>
<hr>
<h2>Suggested Labels</h2>
<p><code>area:cowork</code> · <code>bug</code> · <code>platform:windows</code></p></body></html><!--EndFragment-->
</body>
</html>
What Should Happen?
Scheduled tasks should fire at their next scheduled time after any app launch — including catching up on missed runs per the documented behavior: "If the app is closed when a task is due, it runs on next launch."
lastRunAt should advance each time a task executes — it should never remain frozen across days/weeks while the app is running.
update_scheduled_task (including edits to prompt/SKILL.md content, cron expression, or enabled state) should not affect the scheduler's tick state for any task, including tasks not being edited.
The scheduler should be resilient to file system conditions (e.g., write errors on a synced or junctioned directory) — any such error should be surfaced as a task-level failure, not silently corrupt the global scheduler state.
Error Messages/Logs
Steps to Reproduce
⚠️ The exact trigger is not confirmed. The steps below describe what occurred immediately before the freeze, not a verified minimal reproduction.
Have two or more scheduled tasks active in Cowork on Windows.
Store scheduled task SKILL.md files on a secondary drive that is cloud-synced (in this case, NextCloud on D:\).
With at least one task having run successfully that morning, call update_scheduled_task to edit a task's prompt or SKILL.md path — where the SKILL.md lives on the synced drive.
Observe that all scheduled tasks stop firing from that point forward, including tasks that were not modified.
To confirm the bug is present (without knowing the original trigger):
Open Cowork with at least one enabled scheduled task whose nextRunAt is in the past.
Confirm via list_sessions that no new session has been created for that task.
Quit and fully relaunch the Cowork app.
Confirm via list_sessions that no catch-up session was created on relaunch.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.170
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗