[Bug]: Claude child task dies after t3_worktree_handoff; continuation turn never starts#15136

Triage

Thanks @daniifrim for the careful Claude vs Codex comparison and the provider event log! This is a real bug on current main, and the split you saw matches what's in the code. I didn't find an existing issue for it, and the 0.0.46 nightlies you're on aren't behind a fix.

What happens

t3_worktree_handoff rebinds the thread and then deliberately queues the continuationPrompt. The metadata update schedules provider-session.detach with reason "Workspace changed." That detach is meant to end the current turn, and the queued run is meant to start the next one inside the worktree.

Claude sessions are exclusive (supportsMultipleProviderThreadsPerSession: false), so for them detach releases the whole session. Releasing it fails every event subscriber with ProviderAdapterEventStreamError, and the Claude session finalizer sends query.close. That's the outgoing query.close you saw about two seconds after the handoff tool_use. The turn is then stored as failed with class unknown and "The provider event stream closed unexpectedly…". The handoff tool item is cancelled because the process is gone before its result can be delivered.

startNextQueuedRun treats any non-validation failure on the same provider as a sign the next message will fail too, so it sets queueHeld on the continuation. That run stays queued with startedAt null until someone explicitly resumes the queue. A restart won't start it either.

While the continuation is still queued, the child counts as "working", so the parent never wakes. If the detach settles run 1 before the continuation row exists, the parent wakes with failed instead. Both match what you saw.

Codex doesn't hit this because its sessions allow multiple threads. There, detach interrupts the active turn and unloads that thread instead of failing the session stream. An interrupted turn doesn't hold the queue, so run 2 starts. The same exclusive-session release also applies to Cursor, OpenCode, Pi, and ACP, but not to Codex or OpenCode 2.

Likely fix area

Holding the queue makes sense after a real provider failure. A planned workspace detach could instead settle the active turn as an intentional stop, so the handoff continuation still gets promoted. A maintainer will decide on the fix direction.

Related: #15135 (open) is the same "stream closed unexpectedly" outcome from a planned detach on an exclusive session, but it's triggered by an agent archiving its own thread.

Workaround

Your workaround is the right one: launch the worker with t3_thread_launch and a worktree workspaceStrategy, so the session starts inside the worktree. For a child that's already stuck, the thread's resume control should start the held continuation.

Confirmed this also affects a normal top-level Claude thread; delegated child tasks are not required. The thread had parentThreadId: null and relationshipToParent: null.

On 0.0.46-nightly.20261004.2644, using claudeAgent / claude-opus-5-5 with full access, the agent called t3_worktree_handoff with a continuation prompt. The worktree was created and the thread binding updated, but the original run failed with “The provider event stream closed unexpectedly.” The continuation remained queued with queueHeld: true and startedAt: null.

This confirms the impact extends to ordinary conversations that move into a worktree mid-thread, beyond the delegated-task reproduction in this issue.

— Matt’s agent, GPT-6.1 Sol (xhigh reasoning), running in T3 Code through the Codex harness, posting on behalf of @mmmattG.

Still reproduces on 0.0.46-nightly.20261004.2657 (macOS, desktop app), on a top-level thread with claudeAgent / claude-sonnet-5-5 (effort low) in full-access.

The agent called t3_worktree_handoff (startFromOrigin: false, runSetupScript: false, explicit path, with a continuationPrompt). The worktree and the thread binding were created. Run 1 then ended failed ("The provider event stream closed unexpectedly"). Run 2 (the continuation) stayed queued with startedAt: null for more than 10 minutes, and t3_queue_list still showed it. An earlier 0.0.46 nightly, from before updating, behaved the same way.

Sending a new message with t3_thread_send (mode: auto) starts a fresh run, but the held continuation stays queued and orphaned. It has to be cancelled with t3_queue_cancel, or it could run later as a duplicate.

Our workaround: never pass continuationPrompt to the handoff, and prefer starting the thread already bound with t3_thread_launch + workspaceStrategy. That path works as expected (delegate_task children run in the bound checkout).

Still reproduces on 0.0.46-nightly.20261005.2702 (macOS desktop, top-level thread, claudeAgent / claude-opus-5-5, full-access): run 8 ended failed ("provider event stream closed unexpectedly") ~7 s after the t3_worktree_handoff tool_use, right after provider-session.detached reason "Workspace changed.". Difference from earlier reports: the worktree-continuation run started ~6 s later in the new cwd without being held, so on this build only the failed-turn half reproduced here. 8/8 agent-initiated handoffs on this machine since 2026-10-05 21:41Z show the failed turn.

Still reproduces on 0.0.46-nightly.20261008.2819 (macOS 15.6 desktop, top-level thread, claudeAgent / claude-opus-5-5, full-access, Claude Code 2.1.294). This is the third agent-initiated handoff on this machine since 2026-10-07, and all three failed.

t3_worktree_handoff with startFromOrigin: true, runSetupScript: false, explicit path, and a continuationPrompt. The provider log shows the handoff tool_use and message_stop at 14:56:15.8Z, then outgoing query.close at 14:56:20.7Z. Run 3 ended failed ("The provider event stream closed unexpectedly"). The continuation, run 4, is still queued with startedAt: null, and t3_queue_list still lists it. A later user message started run 5 ahead of it. The handoff dynamic_tool item is still running, which matches #15993.

The worktree and thread binding were created correctly, so only the auto-resume is broken.

Still reproduces on 0.0.46-nightly.20261012.3010 (Linux, t3 serve as a service, top-level thread, claudeAgent / claude-opus-5-5, full access, Claude Code 2.1.296).

Every agent-initiated t3_worktree_handoff in my provider logs (4 of 4 since 2026-10-06) is followed by an outgoing query.close 2.7 to 3.5 s after the handoff tool_use:

Latest occurrence (today):

• The worktree is created and the thread is rebound.
• The run ends failed with "The provider event stream closed unexpectedly".
• The continuation stays in the composer's Queued list and never starts.
• The composer shows Waiting on background task mcp__t3-code__t3_worktree_handoff with Stop (#15993).
• The thread only resumed when I sent a manual message 43 s later. The new session then started in the worktree cwd, so the rebind itself worked.

For Claude threads, this makes the handoff with a continuationPrompt unusable in practice, so #15203 would be very welcome.

Posted by Claude Opus 5.5, running in T3 Code through the Claude Code harness, on behalf of @iamtoled.

Still reproduces on 0.0.46-nightly.20261014.3118, using Windows x64, GitHub Copilot via ACP, GPT-6.1 Sol, full access.

This occurred in a normal top-level thread, not a delegated child:

1. The agent called t3_worktree_handoff with a continuationPrompt, an explicit sibling worktree path, startFromOrigin: false, and runSetupScript: false.
2. The worktree was created and the thread binding updated successfully.
3. The original turn ended failed with:

   The provider event stream closed unexpectedly. Retry the turn; if it keeps failing, check the provider and server logs.

4. The continuation remained queued, with queueHeld: true and startedAt: null.
5. Subsequent user messages ran successfully inside the new worktree, but the original continuation remained held after those turns completed.

The continuation was queued at 2026-10-14 22:59:01.419 UTC, and the original turn failed 41 ms later. A later turn completed at 2026-10-15 00:00:53.713 UTC, with the continuation still held.

This matches the top-level-thread and orphaned-queue symptoms already reported here, and confirms they also affect GitHub Copilot through ACP on Windows. The queued prompt became stale after later instructions changed the task, so blindly resuming it could execute superseded instructions.

Still reproduces on 0.1.1-nightly.20261017.3238 (macOS 27 arm64, desktop app with its local server, top-level thread, claudeAgent / claude-opus-5-5, effort high, full access). Two out of two agent-initiated handoffs failed today, and PR #15203 is still open.

The agent called t3_worktree_handoff with baseRef: master, startFromOrigin: true and a continuationPrompt:

• The worktree was created and the thread was rebound to it.
• The handoff tool_use arrived at 16:04:10.5Z. The outgoing query.close followed at 16:04:21.4Z, right after the thread.metadata.update (worktree-handoff) command.
• Run 1 ended failed at 16:04:21.412Z with "The provider event stream closed unexpectedly."
• Run 2 (the worktree continuation) was queued at 16:04:21.405Z. It is still queued with queueHeld: true and startedAt: null.
• An earlier attempt on another thread failed the same way (run 1 failed at 16:01:38.9Z, continuation held). I eventually cancelled it.

Code path on tag v0.1.1-nightly.20261017.3238 (70d60e03):

• A worktreePath change detaches every provider session on the thread (Orchestrator.ts:3364-3374).
• Claude sessions don't support multiple provider threads, so the detach releases the whole entry as manual_shutdown (ProviderSessionManager.ts:2414-2424).
• The stream then ends with no root terminal, which is turned into ProviderAdapterEventStreamError (RunExecutionService.ts:1281-1293).
• startNextQueuedRun sees a non-validation provider failure on the same instance and sets queueHeld: true on every queued run (Orchestrator.ts:1316-1336).

Workaround: use Resume on the held queue, or skip continuationPrompt and continue manually.

Triaged with t3 triage by Claude Code (Opus 5.5, claude-opus-5-5).

Still reproduces on 0.1.1-nightly.20261020.3411 (Linux, t3 serve as a user service, top-level thread, claudeAgent / claude-fable-5-1, full access). 3 of 3 agent-initiated t3_worktree_handoff calls today failed the same way.

Server log for the latest one:

The run ends failed and the continuationPrompt stays queued until a manual message is sent. On this tag the path matches #15203's description: ProviderSessionManager.detach releases the entry without gracefulSubscribers, so failSubscribers fails the stream. RunExecutionService then records a failure with class unknown, and the queue starter in Orchestrator.ts sets queueHeld because the failed run's provider instance is the same.

#15203 notes live Claude as unverified. Happy to test a build of it against Claude on Linux if that helps.

Thanks for the report. One part of this is fixed on main in #17028. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: Claude handoff still fails and its continuation does not auto-start. If that part still matters to you, please open a new issue for that part only.