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.
5. GeorgeFL7 commented on Oct 12, 2026

   

   GeorgeFL7

   on Oct 12, 2026

   More actions

   Two more occurrences today on Linux arm64, 0.0.46-nightly.20261003.2632 (local server, Claude parent claude-opus-5-5, Codex children via delegate_task). Both threads failed the same way, on different projects, within 40 minutes of each other.

   They match @postoso's variant: the provider session was not idle-released, and the children had already finished. The run consumer had stopped persisting the parent's provider items about 45 minutes before end_turn.

   Timeline (UTC, thread A: provider event log, t3_thread_read, Claude session jsonl)

   • 07:10:57 parent run ordinal:13 starts
   • 07:25:35 last provider-sourced turn item persisted for the run (a reasoning item)
   • 07:25 to 08:12 the Claude session keeps working normally: commits, pushes, opens 4 PRs, calls link_pull_request, and starts 2 delegate_task Codex reviews. All of it is in the provider event log and the Claude jsonl, but none of it is in the T3 timeline.
   • 07:42, 07:47 user messages create runs ordinal:14 and ordinal:15, cancelled with startedAt: null about 1–8 s later
   • 08:06:39 and 08:13:06 both Codex children complete. Their subagent items are persisted on the parent timeline, but no wake run follows.
   • 08:12:09 result stop_reason=end_turn. The last message says it is waiting on the second review.
   • 08:23, 09:30 more user messages create runs ordinal:16 and ordinal:17, also cancelled, never started
   • No query.close at 08:42: the session was still alive 79 minutes after end_turn
   • 09:31 t3_thread_interrupt returns interrupt_requested, and a query.close is logged at 09:31:52. The run stays running.
   • 09:31 t3_thread_send mode auto returns delivery: "steered" into ordinal:13. The Claude jsonl records two queue-operation entries, but no turn starts.
   • 09:32 t3_thread_send mode restart fails:

     OrchestratorDispatchError: Failed to dispatch orchestration command message.dispatch (command:mcp:…:thread-send:unwedge-…-restart).
         at …/0.0.46-nightly.20261003.2632/t3:96908:91
     

   • Settle: Thread 5E1345E5-… has active or blocked work and cannot be settled. A second interrupt is also a no-op.

   Thread B (another project) has the same shape: the parent starts 3 Codex reviews, end_turn at 08:52:23 says it is waiting on them, the children complete, and the parent is never woken. Later user messages are dropped, and Stop does nothing.

   Observations

   • In this variant the persistence stop comes first, and the wedge follows from it. Messages sent while the consumer is dead are not queued; they become runs cancelled before they start. The user gets no error, and the message silently disappears.
   • thread_read still shows activeRunId: ordinal:13, status: running, pendingRequestCount: 0, and an empty queue (t3_queue_list returns []).
   • Workaround: archiving works where Settle doesn't. t3_thread_organize action=archive succeeds and removes the thread from the list. Continuing the work requires a new thread on the same worktree. We didn't restart the server, to avoid interrupting other active threads.
   • The server trace covering 07:25 has already rotated out (the 10 × 10 MB rotation only reaches back about 1 hour here), so I can't show what killed the consumer. A larger trace retention, or a persisted "consumer stopped" error, would make this diagnosable after the fact.