Feature: Increase ScheduleWakeup max delay beyond 3600s for overnight/multi-hour background monitors

Summary

ScheduleWakeup is capped at 3600 seconds (1 hour). Background monitors that need to sleep overnight — e.g. a PR watcher that should check once per day during work hours — must wake up every hour just to check whether it's time to do anything yet. This wastes tokens and clutters agents view with spurious \"Working\" flashes.

Current behavior

From the ScheduleWakeup docs: \"The runtime clamps to [60, 3600]\"

A monitor that finishes work at 6pm and wants to resume at 8am the next morning must schedule 14 consecutive hourly wakeups, each of which checks the time, does nothing, and reschedules again.

Proposed behavior

Allow delaySeconds up to at least 86400 (24h). The tool description already documents the 5-minute prompt-cache TTL tradeoff, so users understand the cost model.

A reasonable set of breakpoints:

• 3600s (1h) — current max, stays warm-ish if cache is kept
• 28800s (8h) — overnight sleep for work-hours monitors
• 86400s (24h) — daily digest / once-a-day agents

Real-world impact

Built a PR/issue watcher plugin (tickler) for Claude Code that uses ScheduleWakeup for background scheduling. Outside work hours it must loop every hour. With an 8h or 24h cap it would fire exactly once at the start of the next workday. The workaround works but is wasteful and noisy in agents view.

Related

• #47518 — visibility into scheduled wakeups / background monitoring