ScheduleWakeup + in-session cron silently stopped firing for ~6h while desktop app stayed open (autonomous overnight session)

Open 💬 0 comments Opened Jul 14, 2026 by pavel-y-ivanov

Summary

During a long-running autonomous coordinator session in the Claude Code desktop app (macOS), ALL in-session scheduling mechanisms silently stopped firing for ~6 hours while the app remained open and the machine awake.

Environment

  • Claude Code desktop app, macOS (Darwin 25.5.0)
  • Model: claude-fable-5
  • Long-running session (heavy context, one prior mid-session crash the same night that required manual re-prompting)

What was armed

  1. ScheduleWakeup (dynamic /loop mode) — next firing scheduled ~23:50 local, ~25-min cadence, re-armed every beat for hours beforehand (working correctly all evening)
  2. A recurring in-session CronCreate job at :41 hourly (had fired correctly at least once earlier)
  3. Persistent + bounded Monitor tasks

What happened

Between ~23:25 PT and ~05:00 PT (~06:45–12:00 UTC 2026-07-14), none of them fired — zero turns in the transcript. The user's manual message was the first activity. Evidence the host was healthy the whole time: detached local child processes (codex CLI tasks) launched from the same session ran to completion during the window, and the desktop app was confirmed open by the user (same setup had worked fine the previous night).

Impact

For autonomous overnight workflows the scheduler is the only thing that makes the agent act; when it dies silently there is no error, no notification, and the model cannot detect the outage from inside (it only exists when invoked). ~6h of review/merge work stalled.

Suggestions

  • Watchdog/self-heal for the in-session timer machinery, or at minimum surface a visible error state when scheduled wakeups are overdue
  • A durable wake path that doesn't share fate with the session runtime

Filed at the user's request after the incident.

View original on GitHub ↗