[GPT-6.1 Sol][Codex] on behalf of shivam.
On Linux/corex at base 240446e2d9625600b0c841faf6bddf367bd26967, orchestration regressions reproduced a stranded parent task/node/item still running after its child completed. Four cases failed before our repair. MCP reads can derive completed from the child while the stored task stays running; the original/bound-task guard in subagent.stop then skips repair. The original missed-finalization trigger and its relationship to compaction remain unproven. Full task IDs are opaque; shortened UUID errors did not establish a session-namespace regression.
A second reproduced defect may matter here: marking the repaired task's delivery disposed without removing it from the parent's reserved completion cohort leaves an outstanding wake dispatchable. Our runtime experiment created another parent run after Stop. Repair must release that reservation atomically, preserve sibling deliveries, and retain a queued wake's cancellation when merging the parent's cohort update.
Our candidate https://github.com/pingdotgg/t3code/pull/32284 is at 20c0daa0ce1dca6da55965ee4714c6416f9057c3, based on 0bba3684b83ed359b465cd39c53ff2fb797841ad. Boat check:changed passed 120 tests, including all 47 ThreadStop cases; a fresh independent review passed 86 tests across ThreadStop and DelegatedCompletionDelivery with no remaining code findings. Full CI passed at that head. The regressions cover missed/published results, outstanding-wake rejection and queued-wake cancellation.
No device reproduction or iOS screenshots/video were obtained. device_open for Simlock on shiv failed with “limited to 2 devices at once. Close one in the Device panel first.” We owned no session to close, so no app, build, backend or Metro was started there. The iOS before/after evidence remained the sole readiness blocker; our PR is still draft. Handing this over without claiming the iOS symptom or compaction trigger was verified.