Delegated-task completion overwrites a just-completed parent run back to waiting, deadlocking the thread behind its own completion notice #20014

What happened

A Claude parent thread stayed on "Thinking" for hours after a short, finished turn. All later messages
and scheduled-task wakes queued behind that turn, and none of them started. The parent had sent a
message to an already-finished delegated child with t3_thread_send and then ended its turn. About 15 s
later the child answered. Its completion overwrote the parent run, which had just reached completed,
back to waiting. The completion notice was then queued behind that run, so the two wait for each
other indefinitely.

Diagnosis

Two writers update the same run row without coordination, and one of them writes a stale full-row snapshot.

1. CheckpointCaptureService loads the run while it is still waiting (:68). It takes capturedAt
   (:106), captures the checkpoint, and then commits {...run, status: "completed", completedAt, checkpointId} (:203). It does not take the thread-dispatch lock.
2. finalizeAppOwnedSubagentTask (Orchestrator.ts:10131) runs under the parent lock (:11294). It
   reads the parent run, and planDelegatedCompletionDelivery (:9925) returns
   {...input.parentRun, delegatedCompletion}. That object is written as a full-row run.updated (:10338).
3. preserveRunRecordedFields (ProjectionStore.ts:646) protects only delegatedCompletion and
   restartCancelledBackgroundWork from stale snapshots. status, completedAt and checkpointId come
   from the payload unchanged. Checkpoint capture explicitly omits delegatedCompletion to avoid the
   reverse race (comment at CheckpointCaptureService.ts:131). Nothing protects this direction.
4. isBlockingRun (Orchestrator.ts:537) treats waiting as blocking. The delivery run is therefore
   created queued behind its own parent. The capture already ran, so nothing moves the parent out of
   waiting again.

The finalize write in the event log is exactly the pre-capture snapshot plus the new cohort. In this
thread, 77 of 78 runs with a delegated-completion cohort settled normally. The one exception is the run
where the child finished 4.9 s after capturedAt. In a case one hour earlier, the gap was 10.5 s, the
run stayed completed, and the delivery run started immediately.

Line numbers refer to 3417bc38. The same code is present on main at 26fffe5a. Later fixes in this
area (#19355, #19631) do not change it.

Steps to reproduce

1. On a V2 Claude thread, start an app-owned child with delegate_task and let it finish.
2. In a later turn, call t3_thread_send to that child thread. This creates an app-owned follow-up task
   node on the current parent run. End the parent turn immediately.
3. Let the child answer while the parent's checkpoint capture is still in progress. The timing window lies
   between finalizeAppOwnedSubagentTask's read of the parent run and its write. A capture commit that lands
   inside that window triggers the bug.
4. The parent run returns to waiting with completedAt: null. The delivery run and every later message
   stay queued, and the UI shows the turn as working.

This is timing-dependent. For a deterministic repro in a test, commit a checkpoint capture between that
read and that write.

Version

0.0.46-nightly.20261014.3105 (upstream 3417bc38). The server is a local rebuild with a small patch to
SQLite and storage cleanup (persistence/Sqlite.ts, storageCleanup.ts, nodeSqliteClient.ts). The
patch does not touch orchestration-v2.

Environment

Linux (Proxmox LXC), systemd user service, web client. Claude Code 2.1.301 with claude-opus-5-5.
Large statev2.sqlite (~20 GB).

Evidence

# orchestration_events, parent thread stream (UTC)
seq      time          event                        run   state written
2480200  16:43:43.696  subagent.updated             1581  follow-up task node created by t3_thread_send
2480235  16:43:53.779  run.updated                  1581  waiting   completedAt=null  checkpointId=null
2480244  16:43:54.232  run.updated (capture)        1581  completed completedAt=16:43:54.232 checkpointId=<set>
2480246  16:43:59.160  subagent.updated             1581  task completed, completionDelivery=claimed
2480247  16:43:59.160  run.updated (finalize)       1581  waiting   completedAt=null  checkpointId=null  delegatedCompletion={open, gen 1}
2480252  16:44:02.501  run.created                  1582  queued, queuePosition=1, userMessageId = cohort delivery messageId
# no later run.updated for 1581; every later run is created `queued`

# payload diff
2480244 -> 2480247: status completed->waiting, completedAt <ts>->null, checkpointId <id>->null, +delegatedCompletion
2480235 -> 2480247: only delegatedCompletion differs

# same pattern, settled correctly (1 h earlier, same thread)
1577 completed at 15:48:59.867; child finished 15:49:10.341 -> run.updated kept status=completed;
delivery run 1578 created `starting`, ran, cohort settled 15:49:19.886

The provider turn of run 1581 is completed. The Claude session was idle-released 30 min later. The
server trace has nothing from this window because it runs at Warn level.

Related issues

• [BUG] V2 waiting run keeps showing Agent is working and offers Stop for finished work when checkpoint capture stalls #15124: a waiting run shows as working while checkpoint capture stalls. In this case capture finished, and the run was reverted afterwards.
• Claude session idle-released while its run waits on a delegate_task child; Stop and Settle then fail permanently #15173: completion notices queue behind a wedged parent run. That run is wedged by an idle release
  while it waits on a child, not by a stale write.
• [Bug]: "Waiting on subagent" chip stuck after t3_thread_send steers into a running delegated child turn; Stop and task_cancel do nothing #19002: an app-owned t3_thread_send node never settles. In this case the node settled, but the parent
  run regressed.

Fix applied or workaround

Nothing has been applied; the thread is left wedged for inspection. Two expected workarounds, both not yet
verified here: Stop on the run, which should take the session-gone interrupt path because the provider turn
is completed, or a server restart.

Possible fixes: write only the delegatedCompletion change instead of a full-row snapshot. Alternatively,
do not let a run regress from completed with a checkpointId to a non-terminal status, for example with
a compare-and-set write like writeIfProviderThreadUnchanged from #19355.

Filed by

Claude Code (claude-opus-5-5). The investigation followed .github/triage/PLAYBOOK.md but was not started with t3 triage.