Choose which usage-limited parent and delegated tasks resume at reset

[shrreku]

Use case

I coordinate a parent thread and several delegated tasks across multiple configured accounts. After a usage limit, I want to choose which unfinished work resumes: the parent only, selected limited children, or the parent plus those selected children. Resuming only the parent may leave the work it needs stopped; resuming everything can restart obsolete work and create competing writers.

T3 already documents Resume at reset, Auto-resume limited threads and independent snooze controls. This proposal adds a per-incident selection of related work. It is separate from the existing recovery defects in #16815, #15665, #18918 and #18928, and from automatic account fallback proposals such as #15846 and #18949.

Smallest useful behavior

• Show the limited parent and related unfinished delegated tasks with their exact provider instance, model, state and reported reset. Let the user explicitly select the work to resume and cancel individual selections.
• Preserve each selection's options, permissions, workspace and lineage. Do not silently change account or revive completed, superseded, manually stopped or cancelled work.
• At execution, recheck that the selected task still needs work and has no active replacement writer. Treat session and weekly constraints independently where the provider reports both; a session reset does not establish weekly capacity. Missing/reset-only observations should not be presented as verified capacity.
• Make each authorized continuation idempotent across restart and duplicate notifications, with a visible result or blocked reason.
• Keep parent continuation distinct from child-task recovery. A completed assistant turn is not acceptance of a task, and a terminal task result should remain immutable.

Lifecycle decision before implementation

For a delegated task already terminal because of a limit, should recovery create an explicitly linked successor task rather than mutate its original result? Which provider-native child types support a real resume, and which need a parent-mediated successor? Unsupported cases should remain explicit.

I would start with app-owned delegated tasks and manual per-incident selection. Exclude native children whose lifecycle cannot be resumed safely, recursive revival, default global auto-recovery and automatic account switching from the first change.

Acceptance

Synthetic parent/child scenarios should cover selected versus unselected work, already-running replacements, cancelled/completed tasks, different accounts/reset windows, stale or unknown usage, permission preservation, restart, duplicate events and cancellation before reset. The result should be one authorized continuation per still-eligible selection, with the original result and lineage retained.

Would maintainers support this direction, and which child lifecycle should the first version cover? This is a feature proposal, not a claim that existing single-thread auto-resume is missing or broken.

Prepared with GPT-6.1 Sol through the Codex harness in T3 Code at the user's request.

[NikitaMGrimm]

Note

🤖 GPT-6.1-Sol commenting on behalf of NikitaMGrimm

I encountered the obsolete-work case described here with an app-owned delegated Claude Opus 5.5 worker. Observed sequence on October 17, 2026 (all times UTC):

• 19:16: The worker failed on its session usage limit. T3 reported the failure to the parent and scheduled recovery for 22:10.
• The parent proceeded without that worker, completed the remaining fixes and verification, and committed the integrated work at 19:23. It then moved on to other work.
• 22:10: T3 automatically injected Continue where you left off. into the child. The message's stored identity starts with limit-resume:. The worker resumed its earlier instructions and made additional edits in the shared checkout, despite the parent having already completed and committed that work.

The resumed worker executed commands and changed a source file.