Session usage limit silently kills background agents and prevents scheduled tasks from firing

Environment

• Claude Code 2.1.71, desktop app on macOS (Darwin 25.5.0), MacBook Pro
• App running and machine awake for the entire period
• Model: claude-fable-5

Summary

A session with three in-flight background agents and a one-time scheduled task hit its session usage limit while idle overnight. The limit terminated the session process, killing the background agents mid-run with no checkpoint, and the scheduled task never fired — with no error, no deferral to the limit reset, and no event in the session transcript explaining why anything stopped.

Exact configuration (for reproduction)

1. In an interactive session, three background subagents were launched via the Agent tool (read-only Explore agents, each a multi-minute template-analysis task).
2. ~15 minutes later, a one-time scheduled task was created via the scheduled-tasks MCP (create_scheduled_task) with fireAt ≈ 4 hours in the future (2026-07-22T05:00:00+09:30). Its prompt's only job was to send_message a resume note back into the originating session. Creation succeeded: "Will run once at 5:00:00 AM (in 3 hours)".
3. The user stopped interacting; the app stayed open and the machine stayed awake.
4. The session reached its usage limit some time after the last interaction (before the scheduled fire time).

Observed

• The Claude Code process exited when the limit was reached. The three background agents were killed mid-run; the session only learned of this ~12 hours later on resume, via a "No completion record was found for 3 background agents… they may have been running when the previous Claude Code process exited" notification. Partial work was recoverable only as raw transcripts.
• At the scheduled fire time (05:00 local) nothing fired. After the limit reset and the user resumed (~13:00 local), the task was still listed as pending/enabled — it had not fired "on next launch", was not marked blocked or failed, and carried no indication the usage limit had prevented it.
• No event anywhere in the session transcript records that the usage limit was reached or that background work was suspended because of it.

Expected

• Background agents should checkpoint/pause when the session hits its limit — not be killed silently. (Being resumable from transcripts is the current partial mitigation, but nothing surfaces this at the time it happens.)
• A scheduled task blocked by a usage limit should either queue and fire on limit reset, or be explicitly marked "blocked: usage limit" — not remain silently pending.
• The session transcript should contain an explicit "usage limit reached — background work suspended" event so the user (and the resumed session) can see what happened and when.

Impact

Unattended/overnight workflows (background agents + a scheduled resume) fail invisibly if the session crosses its usage limit after the user walks away. The user discovers hours later that nothing ran, with no diagnostic trail.