[sunlover7]

Quota-reset recovery currently dispatches its automatic continuation with createdBy: "user". This records a machine-generated prompt as human-authored, despite creationSource: "server". The existing shared user-message presenter only attributes server messages to T3 Code when the actor is agent, so this path also misses that existing attribution.

Set the recovery actor to agent, retaining creationSource: "server". Existing reset timing, recovery identity, command/message deduplication and continuation text are preserved.

This is a small, focused origin-metadata bug fix under the obvious-bug exception. It corrects who authored an existing automatic message. Presentation-default changes are proposed separately in discussion #21320.

Reproduction: pass a failed usage-limit candidate with an armed recovery and a due reset to limitRecoveryCommand; inspect the returned message.dispatch.createdBy. Before: user. After: agent, with server source and the original continuation-of-run identity.

Validation on upstream base d8e9fd267e26b7680f035edc0b40db09d2685dbb:

• The added pure regression verifies nonhuman authorship, unchanged recovery identity and no dispatch before the reset.
• Focused regression plus the existing scheduled usage-limit race scenarios: 20 passed, 67 unrelated tests skipped. Cases cover cancellation, newer human messages, settlement/archive, replacement and snooze races.
• Server typecheck passed. Focused lint passed.
• Commands used: vp test run apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.test.ts apps/server/src/orchestration-v2/runtimeLayer.test.ts -t "quota reset continuation provenance|guards a scheduled usage-limit continuation", pnpm --filter t3 typecheck, and targeted vp lint, all through the local machine-wide build lock.

This was tested without exhausting a live provider quota or changing an installed client's recovery preferences. No client renderer/layout files change in this PR.

Written with GPT-6.1 Sol through the Codex harness.

[macroscopeapp]

Approvability

Verdict: Approved at 6aa0e0c

Macroscope's review found this PR approvable — This is a narrowly scoped provenance correction for existing automatic quota-reset continuations, preserving timing, identity, prompt text, and deduplication. It adds focused regression coverage without changing product defaults, schemas, enforcement, or deployment behavior.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: c6ef3b4
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1c322c52-2ef6-49db-8060-77a2c5915462

Commits

Reviewing files that changed from the base of the PR and between 6407aa3 and bc9e965.

Files selected for processing: 4

• apps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.ts
• apps/server/src/orchestration-v2/Orchestrator.ts
• apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.test.ts
• apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts

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

Walkthrough

Usage-limit recovery continuations now identify their creator as an agent. The orchestrator admits these continuations as subagent follow-ups. Tests cover dispatch timing and provenance, plus delegated completion for quota-recovery continuations.

Changes: Usage-limit recovery

Layer / File(s)	Summary
Recovery continuation dispatch apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts, apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.test.ts	Recovery dispatches use agent attribution. The test checks that dispatch waits for quota reset, verifies its fields, and confirms the command ID remains the same after reset.
Continuation follow-up intake apps/server/src/orchestration-v2/Orchestrator.ts, apps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.ts	The orchestrator admits usage-limit continuations as subagent follow-ups. Tests cover quota-recovery continuations with completed and stopped outcomes.

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

Possibly related issues

• pingdotgg/t3code#21716: This change updates continuation attribution, but does not address the issue's stale overdue arming.
• pingdotgg/t3code#21837: This change admits quota continuations into follow-up handling, but the issue's final-result delivery defect remains separate.
• pingdotgg/t3code#27037: This change adds parent-tracked replacement follow-ups for quota recovery, but does not address child-result aggregation.

Possibly related PRs

• pingdotgg/t3code#27711: Both changes modify the usage-limit recovery command lifecycle.
• pingdotgg/t3code#24511: Both changes modify usage-limit recovery continuations and their provenance.
• pingdotgg/t3code#27000: This PR supplies recovery timing for the continuation path changed here.

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to bc9e9

No actionable issue is established that would prevent merging. Live provider quota-reset recovery has not been exercised.

Security architecture risk: Low · up to 6aa0e

The correction preserves quota eligibility and recovery identity checks and introduces no new endpoint. However, automated authorship also bypasses child-task coordination used for parent tracking. The resulting lifecycle effect needs resolution for automatically resumed child work.

Retained concerns

• Medium · reliability · inferred: Quota recovery can lose parent task ownership when resuming an app-owned child thread after its original task has produced a result. Previously, user/server provenance entered parent serialization and follow-up registration. Agent/server now skips both paths, while delegatedTaskId inheritance applies only to restart continuations. A newly started quota-recovery run can therefore lack the replacement parent task record and completion tracking that the previous provenance supplied. This is a lifecycle-containment concern; its complete effect on parent Stop remains unverified.

Security review details

Security Blast Radius

• inferred — The identified exposure is existing automatic recovery within a thread and, conditionally, its app-owned parent-child execution tree. The inspected change does not establish new cross-tenant reachability, credentials, or provider privileges.

Security Findings and Attack Paths

• inferred — No attacker-controlled authorization bypass was established. The supported concern is an internal execution-ownership transition: automatic recovery can stop entering parent follow-up bookkeeping. Whether this also allows recovered child work to escape parent Stop requires further evidence.

Trust Boundaries and Controls

• observed — Thread-local dispatch locking remains in place. Provider-native subagent threads also retain their read-only dispatch rejection; that control does not resolve the separate app-owned child-thread ownership question.

Resilience and Maintainability Implications

• observed — Repeated recovery construction retains identifiers derived from thread, run, reset, and recovery request identity. Dispatch-time revalidation rejects stale recovery state, including cancellation and snooze changes, rather than trusting the earlier sweep snapshot.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "fix(server): attribute quota continuations to the agent" matches the main change. The diff sets the usage-limit continuation message createdBy from "user" to "agent" in UsageLimitReco…
Description check		The description follows the repository template's main sections. The Problem section explains that quota-reset recovery records a machine-generated continuation as user-authored, and it gives a reprod…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title "fix(server): attribute quota continuations to the agent" matches the main change. The diff sets the usage-limit continuation message createdBy from "user" to "agent" in UsageLimitRecoveryWorker.ts. It also updates the Orchestrator follow-up eligibility for continuations, which is a related part of the same attribution behavior. The title is concise, uses a conventional commit format, and names the affected component.

Full details: Description check

Explanation

The description follows the repository template's main sections. The Problem section explains that quota-reset recovery records a machine-generated continuation as user-authored, and it gives a reproduction. The Change section explains the one-line actor change and what stays the same. The Scope and approval section cites the obvious-bug exception and a related discussion, and it explains why the change qualifies. The Verification section lists focused tests, typecheck, and lint with observed results, and it states what was not checked, such as live provider quota exhaustion. The description does not include an explicit approval comment link for the bug. It also does not state the agent model and harness in the required closing line, although it does mention the GPT-6.1 Sol model and Codex harness. The PR objectives also describe a later child-task ownership change, which the description does not mention, so the description may not match the full PR scope.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

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

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

tested exact head 6aa0e0cfd3620c9a3c2bede3cfdc9240bffbab90 after first running github/main at 32ecd71726fee16f335484c1f95cbce126d461f6 in a separate worktree. installed each with vp i. ran one dev server at a time, using captured pids for shutdown. drove the web app with the repository's playwright and /usr/bin/google-chrome on this linux boat vm.

created a project pointing at /home/user/t3code through the app, selected codex gpt-6.1-sol, and sent real provider turns through the local proxy. main completed one turn. the pr completed the matching turn and two follow-ups. human messages retained user/web provenance, assistant replies retained agent/provider provenance, and the first two replies remained visible after reload. no mocked provider, injected quota state, or demo data was used.

short runtime transcript from read-only inspection of the running servers' persisted projections:

main: codex / gpt-6.1-sol / run 1 completed
main: user / user / web -> assistant / agent / provider
pr:   codex / gpt-6.1-sol / runs 1, 2, 3 completed
pr:   all 3 human messages = user/web
pr:   all 3 assistant messages = agent/provider
ui:   replies 1 and 2 still visible after reload
usage panel, both revisions: Codex could not read usage (JSON-RPC -32600).

reran the existing focused quota regression and scheduled-continuation race cases through blacksmith-check: 20 passed, 67 unrelated cases excluded by the name filter. the command was vp test run apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.test.ts apps/server/src/orchestration-v2/runtimeLayer.test.ts -t "quota reset continuation provenance|guards a scheduled usage-limit continuation". the pr's 10 reported check contexts are also successful. these checks do not prove live quota recovery.

the nine-second recording shows a real codex follow-up streaming and completing on the pr. uploaded playback and seeking were checked in t3's browser.

Not verified

the behavior changed by this pr remains unverified in the real app. the original quota-continuation bug could not be reproduced on main, and automatic reset continuation could not be exercised on the pr. both revisions report Codex could not read usage (JSON-RPC -32600) through this proxy. all real turns completed successfully, without a usage_limit failure or an exhausted quota window with a future reset time. codexUsageLimitResetAt requires that exhausted-window metadata, and recovery also requires a matching failed run. i did not fabricate those prerequisites or deliberately exhaust provider quota.

the existing discussion's child-task ownership concern also remains unverified at runtime. source inspection confirms that changing the continuation to agent/server skips recordSubagentFollowup and parent dispatch locking, while continuedTaskId inherits only restart continuations. a quota-resumed app-owned child after its original task result therefore needs a real check of parent tracking, completion delivery, and parent stop. ordinary root-thread turns do not cover it.

native ios/android, electron-specific behavior, remote/relay/tunnel connections, other providers, and real quota cancellation/snooze/reset timing were not exercised.

main's quota lookup blocker:

the same blocker on the exact pr head:

no source changes or pushes were made. this is an incomplete live verification, not approval based on passing checks.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

addressed the child-task ownership finding in 6407aa370c: quota continuations now take the parent dispatch lock and register replacement follow-up tasks, retaining agent/server attribution. the original task result stays intact. merged github/main without conflicts and pushed the existing fork branch without force.

the two quota cases failed on the missing delegatedTaskId before the fix. after the fix, the focused quota, race, and follow-up checks passed (28 tests). vp run check:changed passed through blacksmith-check: format, lint, both knip passes, graphql, affected typechecks, and 51 tests across five files. two independent reviewers approved the diff.

real provider quota-reset recovery remains unverified. the earlier live verification could not obtain quota metadata from the provider proxy; passing orchestration checks do not prove that live path. no client presentation files changed.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

addressed the child-task ownership concern in 6407aa370cdd98d0562cf5368d92f9a7fc89e4e5. quota continuations now take the existing parent lock and register a replacement follow-up task even with agent/server provenance. the original task result stays intact. reset timing, command identity, and continuation text are unchanged.

extended the existing follow-up table with quota completion and parent-stop cases. both first failed because the recovered run lacked delegatedTaskId; both now pass through the actual limitRecoveryCommand and orchestrator dispatch path. parent tracking, completion delivery, stop disposal, and duplicate recovery assertions pass.

blacksmith verification on this tree: vp run check:changed passed format, lint, both knip passes, graphql generation, typecheck of three affected packages, and 51 tests across five files. the focused quota, follow-up, and recovery-race selection also passed all 28 cases. two independent read-only reviewers approved the diff without findings.

merged github/main at 6fc9144a60c4a5f45089316ddd5f7371bafd3bf2 without conflicts. no rebase or force-push.

live provider quota reset remains unverified; the earlier runtime report's proxy could not supply quota metadata. these automated checks do not claim live quota recovery. no client renderer or layout changes.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

addressed the child-task ownership concern in 6407aa370cdd98d0562cf5368d92f9a7fc89e4e5. quota continuations now take the existing parent lock and register a replacement follow-up task even with agent/server provenance. the original task result stays intact. reset timing, command identity, and continuation text are unchanged.

extended the existing follow-up table with quota completion and parent-stop cases. both first failed because the recovered run lacked delegatedTaskId; both now pass through the actual limitRecoveryCommand and orchestrator dispatch path. parent tracking, completion delivery, stop disposal, and duplicate recovery assertions pass.

blacksmith verification on this tree: vp run check:changed passed format, lint, both knip passes, graphql generation, typecheck of three affected packages, and 51 tests across five files. the focused quota, follow-up, and recovery-race selection also passed all 28 cases. two independent read-only reviewers approved the diff without findings.

merged github/main at 6fc9144a60c4a5f45089316ddd5f7371bafd3bf2 without conflicts. no rebase or force-push.

live provider quota reset remains unverified; the earlier runtime report's proxy could not supply quota metadata. these automated checks do not claim live quota recovery. no client renderer or layout changes.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

merged current main (c6ef3b46ebed34fbefa1706674fe5748254cee18) into the existing head without rebasing. resolved the add/add test conflict by retaining both main's idle-sweep coverage and this pr's quota attribution coverage. pushed bc9e9657826ad0beafcb26fe16f8f225f1f3b10d without force. no production behavior changes in this pass; the diff remains four files.

blacksmith-check passed vp run check:changed github/main: formatting, lint, both knip passes, graphql, three affected package typechecks, and 53 tests across five files. both independent read-only reviewers found no issues on this exact head. the existing child-task ownership fix is preserved.

live provider quota-reset recovery remains unverified because the prior provider proxy lacked quota metadata. this pass makes no new claim of live provider verification. waiting for the new head's CI and mergeability result.