CLI: autoCompact does not fire on scheduled task wake (CronCreate / ScheduleWakeup / /loop dynamic) — session dies at context limit with no intervention

Summary

Claude Code CLI sessions driven by scheduled-task wake paths (CronCreate, ScheduleWakeup, /loop dynamic mode) hit the hard context limit (Context limit reached · /compact or /clear to continue) and die silently. autoCompact does NOT fire on the scheduled-task wake path. Ordinary interactive CLI sessions autoCompact fine; only the scheduled/cron wake path is broken.

This is the CLI-side equivalent of the Agent SDK bug in #44354 (autoCompact broken on resumed sessions because the local message array is empty, so token counts used for the autoCompact decision are wrong). It is distinct from #50554 (opposite problem: compaction summary re-executing /loop commands).

Reproduction

1. Start a long-lived CLI session that polls via a scheduled task. Example: CronCreate with a sentinel prompt, or /loop in dynamic (self-paced) mode, or ScheduleWakeup chained across ticks.
2. Let the session accumulate context across many scheduled wakes.
3. Expected: autoCompact fires before the hard wall.
4. Actual: the next scheduled wake hits Context limit reached · /compact or /clear to continue, churns briefly, then dies. No user is present to run /compact or /clear. The automation stops permanently.

Observed sequence (2026-04-19)

• 14:17 PT — scheduled task fired, completed successfully (pm-sonnet poll tick).
• 14:25 PT — next scheduled task fired, hit "Context limit reached" wall, churned for 1m 59s, died.

Session context: autonomous pm-sonnet polling loop on a trading-system project, running via scheduled-task wake path (CronCreate / ScheduleWakeup class of mechanism).

Expected vs Actual

Expected: autoCompact monitors effective context size across scheduled wakes and fires proactively, same as in interactive sessions. Scheduled/cron sessions should be the PRIMARY use case for autoCompact (no human is watching).

Actual: autoCompact never fires on the scheduled-wake path. Session walks into the hard wall and dies with no intervention. Entire point of autoCompact (preventing unattended death) is defeated for exactly the sessions that need it most.

Suspected root cause

Likely the same class of bug as #44354 — the token-count input to the autoCompact trigger is computed from a local structure that is not representative on the wake path (empty or stale on resume/wake). On interactive sessions the local array is populated normally; on scheduled-task wake the state is reconstructed differently and the counter used by the autoCompact gate is wrong.

Impact

• Any CronCreate-based automation is unreliable for long-running sessions.
• Any /loop-based automation (dynamic or interval) dies at the context wall instead of compacting.
• ScheduleWakeup chains die the same way.
• Autonomous polling, babysitting, and long-horizon agents cannot survive past the context wall. This defeats the main value proposition of scheduled tasks.

Version / Environment

• Platform: Windows 11 Pro
• Shell: bash (via Claude Code)
• Version: <to be filled by user>
• Mechanism involved: CronCreate / ScheduleWakeup / /loop dynamic (scheduled-task wake path)

Related issues

• #44354 — Agent SDK: auto-compact completely broken on resumed sessions (likely shared root cause — local token count not representative of server-side context on resume/wake)
• #42084 — Context limit lockout — @mention agent also fails, session completely unrecoverable
• #19877 — Claude-invocable conditional /compact for automated workflows (workaround requested; would not be needed if autoCompact worked on wake path)
• #47855 — REPL-level context limit check uses stale post-compact token accounting
• #50554 — Compaction summary re-executes /loop (CronCreate) commands from prior session (distinct — opposite direction)