Problem
checkpoint.rollback has no active-run guard. A rollback rewinds the filesystem and the provider conversation to a chosen run ordinal, but nothing in the server refuses to do that while a later run is still live.
Checked three layers, none guard it:
CheckpointRestoreSafety.ts (88 lines) covers worktree isolation only.
Orchestrator.ts:8435 ensureRollback checks capability and model selection only.
- Execution at
CheckpointRollbackService.ts:201-208 filters candidate runs to completed / interrupted / failed / cancelled, which excludes a running run from being rolled back itself, but does not stop the rollback happening while an unrelated later run is still executing.
The only guard is client-local, in ChatView.tsx.
Why this needs a maintainer decision rather than a fix
Adding a guard rejects flows that work today (background tasks, Waiting turns), and the correct boundary is a product question:
- refuse only when a run is actively executing?
- also refuse when a run is Waiting for input?
- what happens to a queued rollback when a run starts between the check and the write?
I did not want to guess, so #16604 deliberately leaves this out and only fixes the three defects with one correct answer each.
Prior art
#15363 ("a thread cannot be archived while its turn is running") is the existing precedent for an active-run guard in this subsystem. Read it before designing one.
Impact
#15124 is the user-visible symptom on the capture side: a V2 waiting run shows "Agent is working" and offers Stop for work that has already finished, when checkpoint capture stalls. Same class of problem, different trigger.
Environment
Found by static audit of the merged orchestrator-v2 work (#2829). Re-verified present at main. No open or merged PR implements it.
Problem
checkpoint.rollbackhas no active-run guard. A rollback rewinds the filesystem and the provider conversation to a chosen run ordinal, but nothing in the server refuses to do that while a later run is still live.Checked three layers, none guard it:
CheckpointRestoreSafety.ts(88 lines) covers worktree isolation only.Orchestrator.ts:8435ensureRollbackchecks capability and model selection only.CheckpointRollbackService.ts:201-208filters candidate runs tocompleted/interrupted/failed/cancelled, which excludes arunningrun from being rolled back itself, but does not stop the rollback happening while an unrelated later run is still executing.The only guard is client-local, in
ChatView.tsx.Why this needs a maintainer decision rather than a fix
Adding a guard rejects flows that work today (background tasks, Waiting turns), and the correct boundary is a product question:
I did not want to guess, so #16604 deliberately leaves this out and only fixes the three defects with one correct answer each.
Prior art
#15363 ("a thread cannot be archived while its turn is running") is the existing precedent for an active-run guard in this subsystem. Read it before designing one.
Impact
#15124 is the user-visible symptom on the capture side: a V2 waiting run shows "Agent is working" and offers Stop for work that has already finished, when checkpoint capture stalls. Same class of problem, different trigger.
Environment
Found by static audit of the merged orchestrator-v2 work (#2829). Re-verified present at
main. No open or merged PR implements it.