claude-code - 💡(How to fix) Fix Scheduled tasks dispatch but never execute — sessions stuck "Running" with zero turns, causing permanent skip-cascade [3 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Scheduled tasks in Cowork dispatch on schedule and update lastRunAt / nextRunAt metadata, but the agent turn never starts. Two failure modes observed:

1. Empty-shell sessions — dispatch creates a session with zero turns, no tool calls, no errors. Target output files never written.
2. Stuck "Running" sessions — dispatch creates a session that shows "Running" indefinitely (25+ min observed) with no visible tool calls. All subsequent scheduled slots are Skipped because the scheduler sees the prior fire as still live. One zombie fire = permanent DoS on that task.

Both modes started after a single prior scheduled-task session hung (a normal working session that never returned). Every dispatch since — across app restarts and PC restarts — reproduces the bug.

Steps to reproduce:

1. Create a scheduled task with a cron expression (e.g. */15 * * * *)
2. Let it run successfully several times
3. Wait for a session that hangs / doesn't return
4. All subsequent fires produce empty-shell or stuck-Running sessions
5. Deleting and recreating tasks with fresh IDs does NOT fix the issue

Ruled out:

• Stale task-ID state (deleted + recreated with fresh IDs — same behavior)
• Concurrency contention (staggered crons 6 min apart — both stuck independently)
• File-path mismatch (aligned output filenames — still no write)
• App-restart-clearable lock (restarted app + full PC restart — no change)
• Credential/connector issue (manual sessions query Outlook M365 + Midnight fine)

Points at: The dispatcher and runtime are decoupled — dispatch succeeds but the worker accepts jobs, marks them "Running", and neither executes nor releases them.

What Should Happen?

Scheduled tasks should execute their agent turn after dispatch, producing tool calls and writing output files. If a session hangs, subsequent fires should not be permanently blocked — a watchdog should force-terminate sessions showing zero turns after N minutes so the scheduler can move on.

Error Messages/Logs

No error messages — that's part of the bug. Sessions are created with zero turns and no errors.

Empty-shell session IDs: local_65ab3334, local_53920f2f, local_88eccd50, local_50afca4a, local_e043415c

Environment: Windows 11 Pro 10.0.26200, Claude Code desktop app (Cowork mode)
Tasks: art-queue-dashboard, are-we-waiting-dashboard
Both use Outlook M365 connector + browser-based lookups + local file writes

Steps to Reproduce

1. Create a scheduled task in Cowork with a cron expression (e.g. */15 * * * *) that uses connectors (Outlook M365) and writes a local HTML file
2. Let it run successfully several times — tasks were working normally for multiple cycles
3. One session hangs / never returns (no specific trigger identified — it just stops mid-run)
4. Every subsequent scheduled fire produces either an empty-shell session (zero turns) or a stuck "Running" session
5. Stuck "Running" sessions cause all future slots to be Skipped indefinitely
6. Deleting both tasks and recreating with fresh IDs + staggered crons reproduces the same behavior immediately

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Version 1.2278.0 (e5213f)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This bug has been left in a live-reproducible state — both tasks show stuck "Running" sessions that can be observed. The skip-cascade continues at 14-15 min intervals.

Key insight: the dispatcher and agent runtime appear decoupled. Dispatch succeeds (session created, metadata updated) but the runtime never picks up the work. A dispatch-side watchdog that force-terminates sessions with zero turns after N minutes would prevent both failure modes.