fix(server): preserve background replies across provider handoffs#32508

Approvability

Verdict: Approved at 0055857

Macroscope's review found this PR approvable — Requested handoffs can proceed without terminating background work, while native-thread restarts wait for that work to settle. Existing queue safeguards remain, with no product-default changes or obvious material risk identified.

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

Explain Change →

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

The automated pipeline stopped on this pull request and will not merge it:

the reviewers still had findings after 3 rounds (the work is on https://github.com/pingdotgg/t3code/compare/main...t3/queue-busy-handoff):

1. [major] apps/server/src/orchestration-v2/Orchestrator.ts:14379: Worse than main: automatic queue resumption can close Claude's session before its background completion notification arrives, losing the pending reply. Claude permits an empty background_tasks_changed roster before task_notification. During that interval, hasPendingBackgroundWork returns false: the roster is empty, no notification is buffered, and the probe ignores wakeEligibleBackgroundTasksByNativeThread. This new listener therefore resumes the account switch and detaches the source process. Main keeps the queued switch held and preserves that process; I checked main's implementation with a scratch regression asserting that an empty-roster event leaves the session open. Preserve pending notification delivery in the session probe before automatically resuming. Fails with: A supported Claude account setup sharing native history: start a background Bash task, queue a switch to another Claude account, and let the root turn finish while the task continues. Claude then emits background_tasks_changed with tasks: [], followed later by task_notification and its wake response. If queue resumption runs between those frames, this head closes the original CLI before it can deliver the notification. Add a regression covering this exact frame order; the existing buffered-output fixtures set bufferedWake immediately and miss the interval before buffering begins.

It stays open for a person to finish or close.

A case that may help here, on 0.1.8 (Linux server, macOS client). The handoff succeeded, then the old session pulled the thread back and blocked every send to the new account, though nothing was running.

1. A thread on Claude account A had background commands and delegated tasks running. A direct send to account B was refused, as in #32296. A send queued during a wake run then handed off fine, and B ran 6 turns over the next 25 minutes.
2. A background command on the old session A finished. A woke and ran a 7-minute turn on its own, which never appeared in the thread. Its T3 MCP tools were rejected for authorization, so its report reached no one. The turn ended with a non-empty result.
3. From then on, every send to B was refused with "The previous provider is still running background agents or commands…". Both Claude processes were idle with no child processes, and every task had reported finishing. Delegated-task completions for the thread were retried every 5 seconds and refused the same way.
4. Picking account A again in the composer let the send through.

The projection showed the thread still on instance B, but its activeProviderThreadId pointed at A's provider thread. A's provider thread had been updated during step 2.

Hint, not verified end to end: provider-thread.updated sets activeProviderThreadId in ProjectionStore.ts, so A's wake activity seems to make each send to B count as a switch again. A's buffered result then counts as background work in ClaudeAdapterV2's hasPendingBackgroundWork.

Drafted with Claude Opus 5.5 (Claude Code in T3 Code) on behalf of @lingolooper-simon.

Hi @voltcrash, these four commits on top of e825f5a address the open finding above and @lingolooper-simon's case: https://github.com/MikaMcFlurry/t3code/compare/e825f5ab83...mika/pr-32508-fix

1. 3618c85dfa covers the finding above. With two real ClaudeAdapterV2 instances sharing history (fixture, no live Claude), an empty background_tasks_changed roster before task_notification let queue resumption close the source query before its notification arrived. The session now stays until that wake is delivered. The regression uses that exact frame order.
2. ca0de8ac4a: a late provider-thread.updated from the retained session no longer resets the active route to A. This looks like the cause of steps 3–4 above, though I haven't reproduced that exact setup.
3. 5414cfda72: if the notification never arrives, thread.stop followed by queue.resume recovers the switch.
4. f48b8682d2: Stop also reaches older retained busy sessions when a newer account fails before its first turn.

Each commit has a test that fails without it. At f48b8682d2, format, lint, knip and typecheck pass, and 605 of 606 tests pass on Node 24.22. The one failure (SQLite statement.stat) also occurs on unchanged e825f5a.

Happy to open this as a PR if that's easier to pick up.

This PR conflicts with main. Rebase it or merge main into it. If it still conflicts after 7 days with no activity, it will be closed automatically.

See the conflict window.

Tested 972a3d0024 against 2dd207aabc.

• The direct-send and queued-resume regressions from #32296 pass. "keeps a busy previous session running when a direct send hands off", "resumes a direct account switch when a background tool finishes", "waits for background work before resuming a queued account switch" and the four "preserves Claude background-work ownership and target selection for a switch %s" variants fail on base (the queued Claude variant times out) and pass on the head.
• The scenarios from 3618c85dfa, 5414cfda72 and ca0de8ac4a also pass with their tests ported onto this head.
• The Stop regression from f48b8682d2 still fails, also when the newest account completes instead of failing: with three accounts, the first two complete but keep probe-visible work, and thread.stop interrupts neither of them. Keeping a session goes by the adapter's probe, while Stop picks other threads from eligible pending turn items or a persisted pendingBackgroundTasks roster. Codex has a real state like that: a persistent dynamic tool keeps its probe busy after the turn completes but is excluded from Stop's eligible items (checked with the real adapter; the three-account run uses a synthetic one). The roster-backed Claude cases I tested, including an emptied native roster with an owed wake, pass.
• #35258 is still needed on top: "refuses a later instance change while a retained hand-off session runs background work" fails on this head. The branches conflict only in that test file and pass together once it is resolved.

A correction to what Ryan and I wrote on #32296: the #22755 gate does not block picking another instance in the composer. Since #31739 (402d0623d5), web and mobile keep such a pick until the next send, which carries it in message.dispatch and reaches this PR's hand-off path. I found no other client path that sends an instance change right away. The gate still applies to same-instance picks that release the session, and to thread.model-selection.set and provider.switch from API or MCP callers during a waiting run.

Merged current main without rebasing and preserved the contributor's handoff behavior. Fixed the merge's duplicate placeholder helper and updated the Claude SDK fixture for renameSession.

Kept explicit queue resumes from reapplying an old failure hold, routed monitor/delegated wakes back to the user's conversation after scheduled fresh runs, and made Stop reach retained sessions whose work exists only in runtime probes. Buffered wakes from retained owners now drain before cross-instance handoffs while ordinary same-provider queue order stays intact. Extended existing regression tables and resolved the four addressed bot threads.

Verification at 1dfbe609af:

• Blacksmith: format, lint, both knip checks, GraphQL generation, and typechecks for all 37 affected packages pass.
• vp run check:changed github/main --concurrency 1: 856 tests pass. The only two failures are SQLite statement.stat tests that also fail on untouched main under the worker's Node 24; this checkout requests Node 26.13.1. No unrelated fixes made.
• The real Claude adapter with controlled SDK frames passes all four account-switch/Stop cases. Focused regressions fail before their fixes and pass afterward.
• Runtime smoke: the real server listened on 127.0.0.1:13773; Playwright with Chrome paired the client, approved a Replay showcase operation, and observed the completed turn. Task servers and the testbox are stopped.
• Two independent reviews approve this exact head. Native Claude multi-account execution remains unverified because Claude is not authenticated on this VM.

Final CI: all 31 reported contexts are successful or intentionally skipped, with none pending or failing. GitHub reports this exact head as MERGEABLE and CLEAN; no unresolved GitHub review threads remain. Ready for Maria's review and merge.

Ran our earlier regression tests for this PR on 1dfbe609af (fixtures, no live Claude; only the tests were ported, no production changes). All six pass here and fail on e825f5a:

• Empty background_tasks_changed before task_notification, switch sent after / queued behind the turn. Your ClaudeAccountSwitchWake cases already cover this.
• A late provider-thread.updated from the retained account after a direct / queued switch to a second Claude account: the route stays on the new account and the next send lands there.
• Emptied roster, task_notification never arrives: thread.stop closes the retained CLI and queue.resume then runs the switch.

The last two have no exact counterpart in the PR's tests (the route test covers Claude→Codex and fresh starts; the Stop variants keep a non-empty roster). Happy to open a small follow-up with them if useful.

check:changed against merge base e2afd2546e: all gates pass, 856/858 tests; the two failures are node:sqlite statement.stat on Node 24.22.