Unattended runs died silently on usage limits for 3 cycles - Task Scheduler reported success #82

New Issue

2026-08-26T20:28:34-04:00

logan commented

2026-08-26 20:28:34 -04:00

Three consecutive unattended runs produced nothing, and nobody was told

.claude/scheduled/logs/ is the whole story:

ws_2026-08-25_0923.log  (66 B)  You've hit your session limit - resets 2:20pm
ws_2026-08-25_2123.log  (66 B)  You've hit your session limit - resets 2:20am
ws_2026-08-26_0923.log  (132 B) You've hit your session limit - resets 2:20pm (x2)

Windows Task Scheduler reports LastTaskResult: 0 for both DRB Session AM and DRB Session PM - the .cmd exited cleanly, so the OS believes the company has been operating normally since 2026-08-25. It has not. No commit has landed since 5fc4e2c (2026-08-25). No Telegram report was sent, because the process died before it ever reached the send.

This is the exact failure mode drb-worksession.md warns about - "a silently undelivered report is the same failure as not running at all" - except one level lower: the run never started, and the silence looked identical to success.

Root cause

run-worksession.cmd is a single unconditional claude -p invocation appending to a log file. It has no notion of failure. A usage-limit refusal, a non-zero exit, and a run that landed three commits are indistinguishable to it.

Secondary: both tasks fire at 09:23 and 21:23, roughly three minutes after an observed usage-window boundary (resets seen at 2:20am / 2:20pm) - the point in the day with the least headroom.

Fix landed

.claude/scheduled/run-session.ps1 - a supervisor wrapping the existing ratified entrypoint rather than replacing it. The authorisation boundary (#62 Decision 1) stays in run-worksession.cmd; the supervisor adds only:

Retry. Up to 4 attempts, 27 min apart, so a cycle survives a transient limit instead of being written off.
Failure is loud. On exhaustion it sends the owner a Telegram message naming the reason and the log file. Silence now means success, not absence.
Delivery confirmation. drb-worksession.md now prints WS_REPORT_SENT as its final stdout line, and only on a confirmed 200 from drb-tg. A run that finishes but never reaches Telegram is notified as its own distinct failure.

Still needs the owner - blocked, I cannot edit Task Scheduler

Both tasks still point at the bare .cmd and still fire at 09:23/21:23. Until this is run, the fix above is inert. The exact command is in the session handoff.

Open question for the board, not for me

If the account's usage ceiling is genuinely the binding constraint, retrying harder only redistributes the shortage. The real choice is between fewer/larger runs and a cheaper model for routine cycles - a spend-vs-cadence call #62 did not settle.

## Three consecutive unattended runs produced nothing, and nobody was told `.claude/scheduled/logs/` is the whole story: ``` ws_2026-08-25_0923.log (66 B) You've hit your session limit - resets 2:20pm ws_2026-08-25_2123.log (66 B) You've hit your session limit - resets 2:20am ws_2026-08-26_0923.log (132 B) You've hit your session limit - resets 2:20pm (x2) ``` Windows Task Scheduler reports `LastTaskResult: 0` for both `DRB Session AM` and `DRB Session PM` - the .cmd exited cleanly, so the OS believes the company has been operating normally since 2026-08-25. It has not. No commit has landed since `5fc4e2c` (2026-08-25). No Telegram report was sent, because the process died before it ever reached the send. **This is the exact failure mode `drb-worksession.md` warns about** - "a silently undelivered report is the same failure as not running at all" - except one level lower: the run never started, and the silence looked identical to success. ### Root cause `run-worksession.cmd` is a single unconditional `claude -p` invocation appending to a log file. It has no notion of failure. A usage-limit refusal, a non-zero exit, and a run that landed three commits are indistinguishable to it. Secondary: both tasks fire at 09:23 and 21:23, roughly three minutes after an observed usage-window boundary (resets seen at 2:20am / 2:20pm) - the point in the day with the least headroom. ### Fix landed `.claude/scheduled/run-session.ps1` - a supervisor wrapping the existing ratified entrypoint rather than replacing it. The authorisation boundary (#62 Decision 1) stays in `run-worksession.cmd`; the supervisor adds only: - **Retry.** Up to 4 attempts, 27 min apart, so a cycle survives a transient limit instead of being written off. - **Failure is loud.** On exhaustion it sends the owner a Telegram message naming the reason and the log file. Silence now means success, not absence. - **Delivery confirmation.** `drb-worksession.md` now prints `WS_REPORT_SENT` as its final stdout line, and only on a confirmed `200` from `drb-tg`. A run that finishes but never reaches Telegram is notified as its own distinct failure. ### Still needs the owner - blocked, I cannot edit Task Scheduler Both tasks still point at the bare `.cmd` and still fire at 09:23/21:23. Until this is run, the fix above is inert. The exact command is in the session handoff. ### Open question for the board, not for me If the account's usage ceiling is genuinely the binding constraint, retrying harder only redistributes the shortage. The real choice is between fewer/larger runs and a cheaper model for routine cycles - a spend-vs-cadence call #62 did not settle.

logan referenced this issue

2026-08-26 20:29:24 -04:00

Two AI spend paths escape config/ai_features entirely, so "AI is off" is not true and #45 cannot measure spend #76

logan referenced this issue

2026-08-26 20:30:54 -04:00

Two AI spend paths escape config/ai_features entirely, so "AI is off" is not true and #45 cannot measure spend #76

logan commented

2026-08-26 20:33:41 -04:00

The exact command, since I was not permitted to run it myself:

$p = 'H:\Cusano-Document-Storage\Logan\Projects\Discord Radio Bot Project\Version 5C\.claude\scheduled\run-session.ps1'
$a = New-ScheduledTaskAction -Execute powershell.exe -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$p`" -Runner run-worksession.cmd -Label ws"
Set-ScheduledTask 'DRB Session AM' -Action $a -Trigger (New-ScheduledTaskTrigger -Daily -At 02:37)
Set-ScheduledTask 'DRB Session PM' -Action $a -Trigger (New-ScheduledTaskTrigger -Daily -At 14:37)

02:37 and 14:37 sit just after the two usage-window resets observed in the dead logs (2:20am / 2:20pm) — the point in the day with the most headroom rather than the least, which is where 09:23 and 21:23 landed.

Close this once it has run and one supervised cycle has reported over Telegram.

The exact command, since I was not permitted to run it myself: ```powershell $p = 'H:\Cusano-Document-Storage\Logan\Projects\Discord Radio Bot Project\Version 5C\.claude\scheduled\run-session.ps1' $a = New-ScheduledTaskAction -Execute powershell.exe -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$p`" -Runner run-worksession.cmd -Label ws" Set-ScheduledTask 'DRB Session AM' -Action $a -Trigger (New-ScheduledTaskTrigger -Daily -At 02:37) Set-ScheduledTask 'DRB Session PM' -Action $a -Trigger (New-ScheduledTaskTrigger -Daily -At 14:37) ``` 02:37 and 14:37 sit just after the two usage-window resets observed in the dead logs (2:20am / 2:20pm) — the point in the day with the most headroom rather than the least, which is where 09:23 and 21:23 landed. Close this once it has run and one supervised cycle has reported over Telegram.

logan commented

2026-08-26 20:50:02 -04:00

Owner ruling 2026-08-26: one run per day, not two. This supersedes the twice-daily cadence in board minutes #62 (Decision 4's Monday board sitting is unaffected — it rides on whichever run falls on a Monday).

Revised command — keep DRB Session AM at 02:37, retire DRB Session PM:

$p = 'H:\Cusano-Document-Storage\Logan\Projects\Discord Radio Bot Project\Version 5C\.claude\scheduled\run-session.ps1'
$a = New-ScheduledTaskAction -Execute powershell.exe -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$p`" -Runner run-worksession.cmd -Label ws"
Set-ScheduledTask 'DRB Session AM' -Action $a -Trigger (New-ScheduledTaskTrigger -Daily -At 02:37)
Disable-ScheduledTask 'DRB Session PM'

Disable- rather than Unregister- so the cadence can be reversed without rebuilding the task.

drb-worksession.md now carries the cadence at the top of the file: there is no second bite at the day, so a run that lands nothing costs the company a full day. One engineering item and one business item, finished, beats three started.

Note this raises the stakes on the supervisor in this issue: with two runs a day a silent failure cost half a day, with one it costs all of it.

**Owner ruling 2026-08-26: one run per day, not two.** This supersedes the twice-daily cadence in board minutes #62 (Decision 4's Monday board sitting is unaffected — it rides on whichever run falls on a Monday). Revised command — keep `DRB Session AM` at 02:37, retire `DRB Session PM`: ```powershell $p = 'H:\Cusano-Document-Storage\Logan\Projects\Discord Radio Bot Project\Version 5C\.claude\scheduled\run-session.ps1' $a = New-ScheduledTaskAction -Execute powershell.exe -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$p`" -Runner run-worksession.cmd -Label ws" Set-ScheduledTask 'DRB Session AM' -Action $a -Trigger (New-ScheduledTaskTrigger -Daily -At 02:37) Disable-ScheduledTask 'DRB Session PM' ``` `Disable-` rather than `Unregister-` so the cadence can be reversed without rebuilding the task. `drb-worksession.md` now carries the cadence at the top of the file: there is no second bite at the day, so a run that lands nothing costs the company a full day. One engineering item and one business item, finished, beats three started. Note this raises the stakes on the supervisor in this issue: with two runs a day a silent failure cost half a day, with one it costs all of it.

logan commented

2026-08-27 03:05:13 -04:00

Closing — the close criterion in this issue is met.

"Close this once it has run and one supervised cycle has reported over Telegram."

The 02:37 cadence fired on 2026-08-27 (owner ruling 2026-08-26: one run per day, DRB Session AM only). The run completed and drb-tg returned 200, so the report reached the owner rather than a log file nobody opens. WS_REPORT_SENT was printed on the confirmed 200, which is the token the supervisor watches for.

The cycle also produced work rather than only a heartbeat, which is the thing the three dead runs were hiding: a deployed commit (d18e4f0, live on /health), two issues closed (#75, #76), two filed (#83, #84), and the overdue #62 Decision 6c deliverables written.

The supervisor's other two guarantees — retry across a usage limit, and a loud Telegram failure on exhaustion — were not exercised this run, because nothing failed. They remain untested in anger. If a future run dies on a usage limit and the owner hears nothing, reopen this.

Refs #62, #68.

**Closing — the close criterion in this issue is met.** > "Close this once it has run and one supervised cycle has reported over Telegram." The 02:37 cadence fired on 2026-08-27 (owner ruling 2026-08-26: one run per day, `DRB Session AM` only). The run completed and `drb-tg` returned **200**, so the report reached the owner rather than a log file nobody opens. `WS_REPORT_SENT` was printed on the confirmed 200, which is the token the supervisor watches for. The cycle also produced work rather than only a heartbeat, which is the thing the three dead runs were hiding: a deployed commit (`d18e4f0`, live on `/health`), two issues closed (#75, #76), two filed (#83, #84), and the overdue #62 Decision 6c deliverables written. The supervisor's other two guarantees — retry across a usage limit, and a loud Telegram failure on exhaustion — were **not** exercised this run, because nothing failed. They remain untested in anger. If a future run dies on a usage limit and the owner hears nothing, reopen this. Refs #62, #68.

logan closed this issue

2026-08-27 03:05:14 -04:00

logan referenced this issue

2026-09-13 17:36:54 -04:00

Board 2026-09-13 — Beachhead checkpoint miss and dev-progress review — COO draft #143

logan referenced this issue

2026-10-04 00:48:29 -04:00

Unattended runner is dead since the Linux move — Task Scheduler/run-session.ps1/drb-tg have no Linux equivalent #193

logan added the area/governance

type

bug

labels 2026-10-05 02:04:39 -04:00