Claude session idle-released while its run waits on a delegate_task child; Stop and Settle then fail permanently #15173

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @areidyOTH for the detailed diagnosis, the code pointers, and the timing evidence. I confirmed this on main (31a9da179). It's a real stuck state, and it's separate from #15124 (that one is a waiting run whose checkpoint capture never finishes).

   Why Stop, Settle, and steer fail

   This matches your report. dispatchRunInterrupt only takes the session-gone path when the provider turn is already not running (Orchestrator.ts, settleOnly). A turn that's still running after its session was released falls through and errors with Provider session … is not active. thread.settle then refuses the thread because a running run counts as active work. Promote-to-steer hits the same dead session, so the queued user message and the delegated-completion wake never start. Only a server restart recovers it, because startup reconciliation is what ends the unfinished run.

   Why the session was released

   Also as you described. releaseIfStillIdle defers only while hasPendingBackgroundWork is true, and for Claude that covers native background tasks, native session subagents, and wake buffers. An app-owned delegate_task child is none of those, so it doesn't pin the session, and the default 30-minute idle timer runs. The gap from end_turn at 10:31:30Z to query.close at 11:01:30Z matches that timer. The session pump marks the session idle when it sees turn.terminal, which starts the timer.

   One correction to the causal chain

   T3 doesn't intentionally keep the run and provider turn running after that terminal. A root turn.terminal that the run consumer ingests is persisted as waiting (RunExecutionService.writeFinalRunEvents), and the provider turn leaves running. Since your captured rows were still running, that terminal likely never landed on the projection, even though the session manager saw it and later released the session. That's the same stranded-projection class as the open PR #14856 and the closed, unmerged PRs #14507 (settle the run when the idle session is released) and #14857 (Stop settles a running turn whose session is gone). The app-owned child explains why the release wasn't deferred, but on its own it doesn't explain a provider turn that stays running after a persisted end_turn.

   The parent_not_active errors aren't established by this capture. delegate_task returns that when the caller has no active run owned by its provider, and this parent run was still running, which passes that check. Releasing the session revokes the MCP credential separately.

   Optional extra evidence

   If you still have the trace, whatever the server logged around 10:31Z when the end_turn result arrived would help narrow it down. An event-write failure would make this the #14856 trigger, while a live consumer that dropped the terminal would be a separate routing bug.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026
3. areidyOTH commented on Oct 3, 2026

   

   areidyOTH

   on Oct 3, 2026

   Author

   More actions

   Thanks. Correction on parent_not_active accepted.

   The server trace around 10:31Z has rotated out (only 3 spans survive for 10:21–10:23), but the persisted event log narrows it down. The run consumer stopped persisting at 10:22:21.623Z, nine minutes before end_turn, not at the terminal:

   • Last consumer-written events for the thread: seq 624482–624485, the first Bash tool call's node.updated/turn-item.updated (completed at 10:22:21.6Z). Its provider event log shows 53 tool_use blocks in total, assistant text, and the result at 10:31:30Z. None of the 52 later tool calls, the text, or the terminal were persisted.
   • The only later events on the thread are the delegate_task subagent/node/turn-item rows at 10:31:20.538Z (MCP command path), then provider-session.updated stopped at 11:01:30.936Z.
   • SQLite was writable in the gap: another thread persisted 53 events at 10:24:52–10:25:47Z, and this thread's MCP-path rows landed at 10:31:20Z. No other thread had provider activity in the gap.

   So it looks like the consumer stopped ingesting (or routing) mid-turn rather than the #14856 write-failure path, though a transient write failure at exactly 10:22:21 can't be excluded without the trace. One possibly relevant detail: a thread-send from another thread queued run 2 on the same provider thread at 10:21:50Z, while run 1 was still preparing (its provider turn started 10:22:09Z).

   Filed by Claude Code (Claude Opus 5.5) via t3 triage.
4. postoso commented on Oct 5, 2026

   

   postoso

   on Oct 5, 2026

   More actions

   Another occurrence on macOS, 0.0.46-nightly.20261004.2657. One difference from the original report: neither delegated child was still pending when the session was released. Both had already completed, and the run stayed running anyway.

   Timeline (UTC, from the provider event log and statev2.sqlite):

   • 01:02:57 run ordinal 10 starts (claudeAgent, claude-opus-5-5)
   • 01:03:53 and 01:07:26 the agent starts two app-owned delegate_task children (codex)
   • 01:09:31 child 1 completes
   • 01:09:44.574 last provider-sourced turn item persisted for the run (a dynamic_tool)
   • 01:09:51 to 01:10:05 the provider log has one more thinking block, a tool_use and its tool_result, and the final assistant text. None of these are in orchestration_v2_projection_turn_items.
   • 01:10:06.611 result / success / terminal_reason: completed
   • 01:13:07 child 2 completes. Its subagent and notification turn items are persisted, so app-sourced writes for this run still worked.
   • 01:43:09.399 outgoing query.close, 30 minutes after the last child completion (not after end_turn)

   State afterwards: run, run attempt, and provider turn are all running; provider session stopped (updated 01:43:09.399Z); both subagent rows completed; no queued runs.

   run.interrupt and a restart-mode send (message.dispatch, via the t3_thread_send MCP tool) both fail the same way:

   OrchestratorDispatchError: Failed to dispatch orchestration command run.interrupt (...)
     [cause]: Error: Provider session provider-session:provider-instance:claudeAgent:thread:<id>:<uuid> is not active.
   

   On the triage question about an event-write failure vs. a dropped terminal: the provider-sourced events stopped persisting about 22s before the result, while app-sourced items kept landing three minutes later. That matches the consumer-stopped-early pattern in the comment above, and points at the #14856 class rather than the terminal alone being dropped. I can't tell you what the server logged at 01:09:44, because the trace had already rotated out. The 10 trace files cover about 15 minutes under this load.