Scheduled-task context injected at session start is sometimes not acted upon (idle greeting instead of executing)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 2, 2026

Description

When a scheduled task (via the mcp__scheduled-tasks mechanism) fires and injects a <scheduled-task> instruction block as context at the very start of a fresh session, the assistant's first turn sometimes replies with a generic idle greeting (e.g. "I'm ready to help. What would you like to work on?") instead of executing the injected instructions — even though the block explicitly states it's an unattended automated run and instructs autonomous execution.

Observed occurrences

Same daily scheduled task, at least 4 known firings:

  • 2026-07-23: idle greeting instead of execution; only ran after the user prompted directly.
  • 2026-07-24: identical failure recurred.
  • 2026-07-25: one clean firing — block arrived mid-conversation (not at session start) and was executed immediately, no lapse.
  • 2026-08-02: recurred again at session start, identical shape to 07-23/07-24. Confirmed via the scheduler's own lastRunAt timestamp that the task fired precisely on schedule; the first assistant turn ignored the injected block entirely and gave an idle greeting instead.

Pattern

The failure appears tied to the block being the first content in a fresh session. The one clean firing happened mid-conversation instead of at session start, suggesting session-start injected context may not reliably register as "act now" versus being treated as inert background/system context.

Impact

Unattended scheduled tasks (e.g. nightly maintenance/consolidation routines) silently fail to run on schedule, and only complete once a human notices in an unrelated later session and asks about it — defeating the point of scheduling.

Environment

Claude Code CLI, Windows 11, task scheduled via mcp__scheduled-tasks (cron-based).

View original on GitHub ↗