Repository navigation
Auto-resume freshly schedules days-old delegated tasks after a server update #21716
Description
What happened
After updating a remote server, six old Claude delegated tasks from the same parent conversation automatically started again without any user action.
These tasks originally failed on usage limits on October 14–17. By October 19, their briefs were stale; other related work had continued in the parent conversation and through subsequent delegated tasks.
The user did not manually resume these tasks or change settings during this occurrence.
Diagnosis
Durable command receipts show that these were newly armed continuations, rather than merely existing timers being restored:
2026-10-19, UTC
11:14:26.394 Settings file modification time
11:14:29.647–.690 Six limit-arm commands accepted
11:14:34.675–35.081 Six limit-resume messages dispatched
At triage, autoResumeLimitedThreads was true. The settings file’s modification time does not establish which setting changed or who initiated the write; the previous value and originating request were unavailable.
The auto-arming branch allows a reset timestamp that is already days in the past, provided it follows the original failure. The next sweep can immediately dispatch the continuation. It has no age limit or check that the delegated brief remains relevant to the parent’s current work.
Executing the released helper with representative timestamps reproduced:
Original failure: October 14
Reset timestamp: October 14
Current time: October 19
No matching recovery arm; auto-resume enabled
First sweep: thread.metadata.update — arm continuation
Second sweep: message.dispatch — "Continue where you left off."
This reproduces the scheduling mechanism, not the complete desktop/update sequence. Why these tasks became newly eligible at that moment remains unresolved.
Steps to reproduce
Proposed reproduction based on the observed state and helper execution:
- Create an app-owned delegated task that fails on a usage limit with a reported reset time.
- Leave it failed while its reset time passes and the parent’s work progresses.
- Run a recovery sweep with automatic resume enabled and no matching recovery arm.
- Observe whether it freshly arms the old failure and starts it on the next sweep.
Expected: stale delegated work should not unexpectedly execute days later without confirming that its continuation is still intended.
Actual: six old briefs received server-generated continuation messages and executed.
Version
Observed after server update:
0.1.1-nightly.20261018.3335 → 0.1.1-nightly.20261019.3348.
Environment
Linux x64 background service, accessed from the macOS desktop. One Codex parent conversation with six app-owned Claude child threads.
Evidence
All six original child threads had usage-limit failures and no successful run before this occurrence.
Following automatic resumption:
- Three child runs completed.
- Three child runs were interrupted.
- No active Claude child run remained at triage.
The generated messages contained:
text: "Continue where you left off."
createdBy: "user"
creationSource: "server"
command prefix: limit-resume:
Subsequent successful tasks covered related UI work, but complete replacement of each original brief has not been established.
Related issues
#21091 and PR #21114 concern cancellation failing to disarm usage-limit recovery.
This occurrence does not establish cancellation before resumption. It demonstrates fresh arming of overdue failures, which may need separate handling.
Fix applied or workaround
No fix applied during triage. Existing continuations must be cancelled individually; disabling the global auto-resume preference alone does not disarm existing recovery records.
Screenshots are available and can be attached manually.
Filed by
GPT-6.1-Sol through the Codex harness, following the T3 Code triage playbook.
Activity
juliusmarminge commentedon Oct 19, 2026
Note
Grok responding on behalf of Julius.
Accepted as a bug, scoped to resuming old limit failures with no age limit. With auto-resume on, the recovery sweep arms any failed usage-limit thread that has no matching arm, as long as its reset time falls after the failure. It doesn't check how long ago that reset was (UsageLimitRecoveryWorker.ts:26-47). The next sweep then dispatches "Continue where you left off." once the reset has passed (UsageLimitRecoveryWorker.ts:49-70). A failure from days ago is therefore armed and resumed within seconds.
Auto-resume is off by default (settings.ts:1138). Tasks that failed days earlier being armed only now fits the setting being turned on at that write, but we can't confirm that. An existing arm keeps its own auto-resume flag, so turning the setting off later doesn't cancel it (ProjectionStore.ts:3608-3611). Disarming on stop is tracked in #21091.
test(server): reproduce #21716 stale usage-limit failures auto-arming
fix(server): auto-recovery no longer arms usage-limit failures whose …
djfbryant commentedon Oct 24, 2026
Confirming another instance on 23–24 October 2026, with Auto-resume limited threads enabled.
Impact: I saw old tasks restart repeatedly, and this used a substantial amount of my subscription allowance. The amount has not been measured. This is costly because old delegated work can compete with current work for the same allowance, hit the limit again, and then resume at the next reset.
My agent checked the durable thread records through T3's read tools. Two examples, with private project details omitted:
For task A, the first two resumed runs failed on usage limits; the last completed. Task B's resumed run failed. The continuation messages have all three identifying fields:
This confirms usage-limit recovery started these runs; these were not manual continuation messages. The records do not establish whether the first recovery was newly armed at that moment or had been armed earlier. A server update or crash as the trigger for this occurrence has not been established.
Code check: At upstream main
2c592a1086, UsageLimitRecoveryWorker.ts still permits an old failure to be armed after its reset is long past, provided the reset follows the original failure. Each new usage-limit failure with a new run/reset can create another recovery opportunity. This path has no task-age limit or retry cap, and does not check whether the parent still needs the delegated work.A small isolated replay of that helper's actual function body produced:
That replay verifies the scheduling decision, not the full running application. No code, settings, or thread recovery choices were changed during this investigation.
Please include the usage impact and repeated subsequent limit-reset retries in this issue's scope. A fix should prevent stale delegated work from silently consuming further allowance and make pending recoveries easy to find and cancel.
Posted at my request by GPT-6.1-Sol through the Codex harness in T3 Code.