Session-limit interactive prompt blocks queued scheduled prompts (CronCreate//loop) in unattended sessions

Status Closed — not planned
Reported on v2.1.214
Maintainer reply None cached
Activity 2 comments · opened Jul 18, 2026 · closed Aug 17, 2026

Environment

  • Claude Code CLI 2.1.214, Windows 11 Pro 10.0.26200, PowerShell

Description

When an interactive session hits the usage/session limit mid-run (You've hit your session limit · resets <time>), the CLI now shows an interactive prompt offering to continue with extra usage or wait until the limit resets.

If the session is unattended (e.g. a long-running /loop driven by in-session scheduled prompts via CronCreate), the queued prompts stay blocked behind that interactive prompt after the limit resets — the queue only resumes once a human presses a key.

Expected behavior

Previously (or expected): queued prompts auto-resume after the limit resets, so unattended fixed-interval loops survive the reset without human interaction.

Actual behavior

Session stays parked on the interactive limit prompt indefinitely; scheduled/queued prompts pile up and nothing executes until a keypress.

Repro

  1. Start a fixed-interval loop (/loop 30m <prompt>) that spawns subagents doing real work.
  2. Let the session hit the usage limit mid-run.
  3. Wait past the reset time with no interaction.
  4. Observe: CLI still sitting on the limit prompt; queued cron prompts not executing.

Ask

A setting/flag (settings.json or env) to auto-select "wait and resume at reset" so unattended sessions continue automatically — or make that the default when there is queued input.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗