Orchestrator V2: safely replace a worker thread and retire its predecessor

[RoySalisbury]

Problem or use case

After moving a coordinator and several worker lanes from Claude to fresh Codex threads, the replacements were working while the original threads still appeared as waiting. The originals had been told to retire and renamed accordingly, but those messages and titles did not settle their T3 lifecycle state.

I would like an explicit Orchestrator V2 workflow for replacing an existing thread as the owner of a workstream, with a recorded successor relationship and reliable predecessor retirement after the handoff succeeds.

Observed behavior

• T3 Code 0.0.46-nightly.20261006.2735, Linux x64, observed October 7, 2026.
• Source provider/model: claudeAgent / claude-opus-5-5; destination: codex / gpt-6.1-sol.
• The coordinator created ordinary top-level successor threads using concise handoff files. These were independent conversations used as coordinator/worker lanes, rather than native delegated-task records or an in-place provider switch.
• Four predecessors—the coordinator and three workers—remained unsettled after their successors took over. Completed predecessor turns and retirement acknowledgements did not change that state.
• The old coordinator also retained an obsolete queued worker report. One old worker received a late completion from an inherited background test and acknowledged retirement again.
• Explicitly settling the four predecessors, and cancelling the identified obsolete queued report, succeeded. The successors continued independently.

This establishes missed cleanup in the agent-managed replacement sequence. It does not establish a failure of the existing settle operation or observed duplicate execution. A completed turn can legitimately leave a thread waiting for more work, so automatically settling every idle thread would not address the distinction.

Suggested smallest useful scope

Expose an explicit replacement/retirement workflow through the existing thread controls and agent tools:

1. Record a predecessor/successor link, visible in both threads and available to the coordinator. The existing workspace and handoff artifacts should be selected explicitly through the current launch controls.
2. Confirm that the successor has started and accepted ownership before retiring the predecessor. Launch failure should leave the predecessor recoverable; retries should not create multiple owners.
3. Settle the predecessor as superseded while preserving its history and a link to the active owner. Show the active owner clearly in the thread list.
4. Account for pending messages, scheduled wakes, and background completions during retirement. Identify obsolete work for cancellation or redirect relevant reports to the successor, preserving pending user input and ongoing external builds/tests. Late reports should not silently reactivate a retired owner.

The first useful version could be an explicit replacement relation plus a checked retirement operation using the existing launch, messaging, scheduling, and settlement controls. The precise API and acknowledgement mechanism are open for maintainer guidance.

Related work

• #8433 was closed after Orchestrator V2 landed, with an invitation to open focused follow-ups for missing behavior in a V2 build. This request concerns the replacement lifecycle after successful launch.
• #8754 was closed as a duplicate before V2. Its related handoff/continuation PRs #7487, #8452, and #8492 are closed without merging.
• #8847 remains open, but proposes settling and opening a blank draft without carrying a handoff or transferring workstream ownership.
• #17068 covers recovery when an in-place provider switch cannot fit the destination context. That triggered this workaround; this proposal covers retirement after fresh successor threads successfully take over.

I searched existing issues and Ideas discussions and found these related proposals, but no complete duplicate of the observed V2 replacement/retirement gap. I am submitting this for consideration as a focused feature request.