[juliusmarminge]

Problem

A delegated child that fails on a usage limit while its parent is open gets an auto-resume armed for its reset. If the parent is settled before the reset, the armed resume still runs the child, and the child's delegated-completion wake reopens the settled parent and starts a new run on it. https://git.cafe/pingdotgg/t3code/pulls/27951 only stopped new arms for children of settled parents; an already-armed resume still fired. Reproduced on main (cefb544) with the runtime test below, through the real orchestrator.

Change

The usage-limit continuation guard in Orchestrator.dispatchMessage now also refuses a resume when the thread is a subagent whose direct parent is settled. The parent row is read only for subagents, only on this path, and inside the child's serialized dispatch, so a parent settled after the sweep read it is covered.

When the refused command still matches the thread's armed recovery (same run and request id), the refusal retires it: autoResume: false with a fresh request id, the same state as "Cancel auto-resume". Reopening the parent later does not revive it, and the sweep has nothing left to offer for that thread. A stale resume whose request id no longer matches (the user re-armed in the meantime) takes the existing no-op path, so it never overwrites a newer choice. If the parent is reopened before the reset, the child resumes as before.

The user guide's usage-limit section now says a delegated task's continuation is cancelled if its parent is still settled when the reset arrives.

Scope and approval

Fixes #30144

Triaged via the automated issue flow.

Verification

Server-only change with no visible surface, so no captures. Proof is one regression in runtimeLayer.test.ts, "retires a usage-limited subagent resume once its parent settles", through the real orchestrator: child armed while the parent is open → parent settled → reset passes → the sweep's resume is dispatched. It asserts no new child run, the parent still settled, the recovery disarmed; that unsettling the parent afterwards yields no limit-resume: and no limit-arm:; that re-dispatching the same saved resume does not leave the child armed but stuck; and that a stale resume after an explicit re-arm leaves the user's recovery untouched.

Red with main's Orchestrator.ts (the child starts a second run):

FAIL  runtimeLayer.test.ts > usage-limit recovery > retires a usage-limited subagent resume once its parent settles
AssertionError: expected [ { …(16) }, { …(16) } ] to have a length of 1 but got 2

Green at this head:

vp test run runtimeLayer.test.ts -t "limit"                            Tests  21 passed | 92 skipped (113)
vp test run ProjectionStore.test.ts UsageLimitRecoveryWorker.test.ts   Tests  56 passed (56)
vp run check:changed                                                    passed (format, lint, knip, typecheck, tests)

Not checked: a live provider hitting a real usage limit through child completion and parent wake (no test environment can trigger a real Claude limit), and the reporter's macOS desktop build. The change is server-side and platform-independent. Delegation to a linked environment uses a different lineage and is not covered by this change (the same scope as https://git.cafe/pingdotgg/t3code/pulls/27951).

Claude Opus 5.5 (Claude Code in T3 Code), with reviews by GPT-6.1 Sol (Codex) and Claude Opus 5.5.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 0b048fa

Macroscope's review found this PR approvable — Cancels a delegated task’s scheduled usage-limit resume when its parent remains settled, preventing unwanted work from reopening the parent. The change is narrowly scoped and preserves newer recovery choices without changing scheduling defaults.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The usage-limit continuation path now rejects a delegated child’s resume when its parent is settled and disarms the matching recovery. Tests cover stale continuation commands, and the thread sidebar guidance describes the cancellation rule.

Changes: Delegated usage-limit continuation

Layer / File(s)	Summary
Parent settlement check and recovery handling apps/server/src/orchestration-v2/Orchestrator.ts, apps/server/src/orchestration-v2/runtimeLayer.test.ts, docs/user/thread-sidebar.md	The orchestrator checks whether the child’s parent is settled before accepting an automatic continuation. It disarms matching recovery when the parent is settled. Tests verify that a stale command does not resume after the parent is unsettled or recovery is rearmed. The sidebar guidance states that settling a thread cancels a delegated task’s pending continuation.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: High

Possibly related issues

• pingdotgg/t3code#27944 — Reports delegated children resuming after their parent is settled. This change addresses the dispatch path, but does not change the sweep-level behavior described in the issue.

Possibly related PRs

• pingdotgg/t3code#29838 — Changes usage-limit continuation attribution and delegated follow-up tracking in the same continuation path.
• pingdotgg/t3code#28360 — Disarms usage-limit recovery when a thread settles.
• pingdotgg/t3code#27951 — Prevents new recovery arming for a child of a settled parent; this change handles a recovery armed before the parent settled.

Suggested labels: bugfix

Suggested reviewers: t3dotgg, maria-rcks, fixfon

Merge Risk: Moderate · up to 0b048

A delegated task can resume after its parent was settled and then reopened, despite the intended cancellation. Retire the armed recovery on settlement before merging.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: settling a parent cancels its delegated child's already-armed usage-limit auto-resume. It matches the code change in Orchestrator.dispatchMessage, the regression test,…
Linked Issues check		The linked issue #30144 has one active direct target and one coding requirement. The requirement is that settling a parent cancels, or skips at fire time, an already-armed usage-limit resume of its de…
Out of Scope Changes check		The reviewed changes touch three files: apps/server/src/orchestration-v2/Orchestrator.ts (settled-parent guard and recovery retirement), apps/server/src/orchestration-v2/runtimeLayer.test.ts (regressi…
Description check		The description includes all required sections. It clearly explains the problem, the implementation, scope and approval, focused verification results, limitations, and tool usage.

Full details: Title check

Explanation

The title names the main change: settling a parent cancels its delegated child's already-armed usage-limit auto-resume. It matches the code change in Orchestrator.dispatchMessage, the regression test, and the docs update. It uses the conventional commit format and avoids vague wording.

Full details: Linked Issues check

Explanation

The linked issue #30144 has one active direct target and one coding requirement. The requirement is that settling a parent cancels, or skips at fire time, an already-armed usage-limit resume of its delegated child, so the child does not run and the parent does not reopen. The reviewed changes implement this in apps/server/src/orchestration-v2/Orchestrator.ts. The dispatch guard reads the direct parent only for subagents and refuses the continuation when the parent is settled. A refused command that matches the armed recovery (run and request id) is retired with autoResume: false and a fresh request id. A stale command takes the no-op path and does not overwrite a newer re-arm. runtimeLayer.test.ts (retires a usage-limited subagent resume once its parent settles) covers the child run count, the parent state, reopen behavior, and stale replay. The incremental diff from the previous reviewed head to head for Orchestrator.ts returned no text, so the guard is unchanged since the prior PASS. The whole-PR diff could not be read because changed blobs are missing from the checkout, and a full file read of Orchestrator.ts was truncated before the guard, so the guard was not re-read directly at head. The prior conclusion and the current PR description are the evidence for the guard. The incremental changes to runtimeLayer.test.ts and docs/user/thread-sidebar.md were not read. The #27951 linked-environment lineage is excluded, as the issue text and PR description state.

Full details: Out of Scope Changes check

Explanation

The reviewed changes touch three files: apps/server/src/orchestration-v2/Orchestrator.ts (settled-parent guard and recovery retirement), apps/server/src/orchestration-v2/runtimeLayer.test.ts (regression and stale-command test for the same path), and docs/user/thread-sidebar.md (documents that settling a thread cancels pending continuations of tasks it delegated). Each change relates to #30144. The test and documentation support the guard. No unrelated implementation change was identified. The same limits as the linked-issue assessment apply: the whole-PR diff was unavailable, the Orchestrator.ts guard was not re-read at head, and the incremental test and documentation diffs were not read.

Finishing Touches

Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: fix/issue-30144
• File: .coderabbit.config.ts
• Commit: 0b048fa
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: db8a4f98-a836-4840-8980-57fb5a8dc475

Commits

Reviewing files that changed from the base of the PR and between 1effe8b and 0b048fa.

Files selected for processing: 1

• docs/user/thread-sidebar.md

Files skipped from review as they are similar to previous changes: 1

• docs/user/thread-sidebar.md

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[coderabbitai]

• Fix comments: Fix CodeRabbit comments on this PR

Dismissing prior approval to re-evaluate 0b048fa

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	+16 B (+0.3%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	+16 B (+1.3%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	21.5 KiB	21.6 KiB	+41 B (+0.2%)	24.4 KiB	✅
Codex	Live turn messages	1	2	+1 (+100.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.9 KiB	21.9 KiB	0 B (0.0%)	24.4 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: cefb544 · PR result: 0b048fa · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.