[Bug]: Claude t3_worktree_handoff still fails the turn and its continuationPrompt never starts#22971

Additional report from Linux using GPT through the Claude Code harness, with a check of current upstream source before posting.

Observed environment

• T3 Code server: 0.1.2-nightly.20261021.3473, running as a Linux x86_64 user service.
• Driver: claudeAgent (claude-agent-sdk.query), model: codex/gpt-6.1-sol via a custom provider, effort high, full access (bypassPermissions).
• Local Claude Code currently reports 2.1.309.
• Normal top-level thread initially attached to the project's root checkout.

Observed sequence on 2026-10-24 (UTC)

The agent called:

The branch name and task instructions above are anonymized. The relevant provider/server logs are:

The worktree creation/binding succeeded. The handoff run was persisted as failed, and the UI showed:

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

It also showed Waiting on background task mcp__t3-code__t3_worktree_handoff, matching #15993. After a subsequent Stop/Resume interaction, a previously queued user follow-up ran in the new worktree. At inspection time, the separate handoff-continuation run was still queued with no startedAt. The query.open above therefore does not demonstrate that the continuationPrompt auto-resumed.

This adds a GPT-backed Claude Code reproduction: the lifecycle failure follows the Claude harness/session, rather than requiring a Claude model. T3 itself issued query.close about 5 ms before the ingestion warning.

Current release / main source check

I have not runtime-reproduced this on the newest release, and have not upgraded the affected installation. The following is source inspection only:

• Latest stable: v0.1.2.
• Latest published nightly at checking time: v0.1.3-nightly.20261023.3592.
• Checked main: aaf4a901c490da4f0943afe1d941f3a8d58dc1c8.

All three refs have the same ProviderSessionManager.ts blob (e82995d1db77f3beb2ecc20c2fff6a59a7dde33e). The relevant path remains:

1. A worktree-path change schedules a session detach with Workspace changed. (Orchestrator.ts).
2. Detaching the last thread from a session without multiple-provider-thread support calls releaseEntry with reason: "manual_shutdown" and no gracefulSubscribers (ProviderSessionManager.ts).
3. That release calls failSubscribers, producing ProviderAdapterEventStreamError (release path, error construction).
4. Run ingestion still handles non-interruption failures as run failures (RunExecutionService.ts).

#22825 (draft) and #15203 are both still open/unmerged at checking time. #22863 was closed as a duplicate with an explicit note that closure did not mean the fix had shipped. Posting here instead of opening another duplicate.

Posted by a coding assistant on behalf of @betacatsling; private project paths, conversation IDs, and task text omitted.

Another report, from the macOS desktop app: server 0.1.2-nightly.20261021.3473 (desktop-managed), darwin arm64, Node 26.12.1, Claude Code 2.1.310. Driver claudeAgent / claude-opus-5-5, full access. The user reports it also happened on earlier nightlies and in unrelated repos.

Frequency: 5 of 5 agent-initiated t3_worktree_handoff calls in the retained provider logs (2026-10-15 → 2026-10-25). All five passed a continuationPrompt.

Why the continuation doesn't start: in all five cases the continuation run was set to queueHeld: true within ~10 ms of being queued, right after the handoff run was marked failed. It stayed held until the user clicked Continue (after 5 s, 7 s, 12 s, 1 m 39 s and 24 m 21 s). The cases that looked "automatic" were also manual clicks. This matches the hold in startNextQueuedRun. The handoff run's failure has class unknown (ProviderAdapterEventStreamError), which is neither undefined nor validation_error, and it's the same provider instance, so every queued run for the thread is held. That includes the handoff's own continuation and, in one case, a user message that was already queued.

Most recent case (UTC):

Not verified here: the inner Workspace changed. cause quoted above (my server traces had already rotated past these events), whether Codex threads are affected on this machine, and whether #15203 fixes it.

Investigated with t3 triage by Claude Code (Claude Opus 5.5).

Still reproducible on 0.1.3-nightly.20261027.3754, this time with claudeAgent / claude-sonnet-5-5 (full access), so it isn't specific to Opus.

• t3_worktree_handoff was called with a continuationPrompt. The worktree and branch were created and the thread was rebound (t3_worktree_status reports attached: true).
• The response reported continuation: { status: "scheduled", delivery: "queued" }, but the continuation never started on its own. Afterwards t3_queue_list was empty and the thread was idle. I had to send the same prompt manually to continue.
• The project setup script (init-worktree) did start and finish normally (files copied, flutter pub get done within ~25 s), so the handoff itself works. Only the turn end and the continuation delivery are broken.

Another report from Linux (Ubuntu 26.04), server 0.1.2 as a user service, claudeAgent / claude-opus-5-5, full access. Both agent handoffs on 2026-10-27 went the same way, and the state database shows where the continuation goes:

1. The handoff returns continuation: scheduled, delivery: queued, and the worktree and thread binding are correct.
2. About 2 ms later the session detaches, and interrupting the turn fails with ProviderAdapterInterruptError: Failed to interrupt claudeAgent provider turn.
3. The calling run is recorded as failed.
4. The continuation run is stored as queued with queueHeld: true, so nothing starts it.

Starting the held queued run by hand works, and it then runs normally in the worktree. In one thread that happened after 15 minutes (15:27:19 to 15:42:38 UTC). In the other, the user sent a new message after 5 minutes, and the stale banner from #15993 stayed for about two hours.

So on this build the continuation isn't lost. The failed handoff run holds the queue it just filled.

Still reproduces on desktop 0.1.3 (macOS), claudeAgent / claude-opus-5-5, on every handoff. The server trace shows why the turn ends as a failure: the session is torn down before the turn is interrupted, so the interrupt has nothing left to write to.

Order of spans after WorktreeMcpService.handoff succeeds (worktree created, thread.metadata.update, continuation message.dispatch queued, setup script started), all within the same second:

1. ProviderSessionManager.removeLiveEntry
2. ProviderSessionManager.failSubscribers
3. ClaudeAdapterV2.interruptTurn → Failure

   1	ProviderAdapterInterruptError: Failed to interrupt claudeAgent provider turn …ordinal%3A1%3Aattempt%3A1.
   2	[cause]: ClaudeAgentSdkQueryRunnerError: Claude Agent SDK query failed.
   3	[cause]: Error: ProcessTransport is not ready for writing

4. ProviderSessionManager.closeScopeWithin → detach → RunExecutionService.writeFinalRunEvents

The provider event log ends with outgoing {"type":"query.close"} right after the assistant's t3_worktree_handoff tool_use (stop_reason: tool_use). No tool_result is ever written for it. So the run is finalised as "provider event stream closed unexpectedly", and the pending tool call shows up as "Waiting on background task mcp__t3-code__t3_worktree_handoff" in front of the queued continuation (#15993).

Suggested fix: for a handoff-initiated detach, settle the turn as completed/handed-off (or answer the pending tool_use) before failSubscribers/closing the query, rather than interrupting an already-closed transport.

Reported by Claude Opus 5.5 (an AI agent running inside T3 Code) on behalf of the account owner, who reviewed this comment and asked for it to be posted.

Still reproduces on stable v0.1.5 (Linux, server as a system service, --mode web), claudeAgent / claude-opus-5-5, auto mode. Four of four agent-initiated handoffs today failed the same way, on 0.1.2 and again after updating to 0.1.5:

• handoff tool_use, then T3's own query.close about 1 s later, then ProviderAdapterEventStreamError … [cause]: Error: Workspace changed. and failed to interrupt turn after ingestion failure (ProcessTransport is not ready for writing).
• Once, the continuation started on its own about 90 s later in the worktree. Another time it sat in the queue with "Send now" while the handoff tool item still showed "Waiting on t3_worktree_handoff".

From the 0.1.5 bundle, the handoff path never goes through the interrupt-first flow T3 already has. The orchestrator handles a thread.metadata.update that changes worktreePath like archive and settle (reason "Workspace changed."). It emits provider-session.detach, and for the Claude adapter that becomes releaseEntry({ reason: "manual_shutdown", detail: "Workspace changed." }), which calls failSubscribers before anything interrupts the turn. The model and session change path (provider-turn.restart → interruptAndAwaitTerminal) interrupts the running turn and waits for its terminal event before detaching. Routing a workspace change on a thread with an active run through that path, or deferring the detach until the run's terminal event, should make the handoff turn end as completed or interrupted instead of failed.

Still reproduces on stable v0.1.5 in the macOS desktop app (T3 Code (Beta) with its local server, darwin arm64, Node 26.12.1), top-level thread, claudeAgent. One detail that earlier reports do not show is that the continuation was overtaken by a later user message.

Timeline from the state database and server.trace.ndjson (UTC, 2026-10-30):

• 18:07:48.883: t3_worktree_handoff returns continuation: scheduled, delivery: queued. The continuation run is created with id …:ordinal:13.
• 18:07:48.890: the calling run (ordinal 12) ends failed with "The provider event stream closed unexpectedly". In the same second ClaudeAdapterV2.interruptTurn fails with ProviderAdapterInterruptError: Failed to interrupt claudeAgent provider turn …ordinal:12….
• 18:10:03.901: the user sends a new message. Its run (ordinal 14) starts at once, 18:10:03.923.
• 18:10:19.887: the continuation starts only after run 14 completed (18:10:19.465). Its projected ordinal is now 15, although its id still says ordinal:13.

So the queued continuation does not run first. It runs after whatever the user sends next, out of order, with a prompt that is stale by then.

The successful handoff's dynamic_tool item in run 12 is still running, inside a run that ended failed. That keeps the "waiting" indicator in the thread while t3_queue_list is empty, as in #15993.

Posted by Claude Code (claude-opus-5-5) via t3 triage on behalf of the account owner, who reviewed it.

Posted by Opus 5.5 on behalf of James Heinemann

Still happening on 0.1.6-nightly.20261029.3892 (WSL2, claudeAgent / claude-opus-5-5), 6 of 6 agent-initiated handoffs since 2026-10-19. The handoff run ends failed, and the continuation sits queued with queueHeld: true until I click Resume. This matches the diagnosis in #24444.

Continuation waits across the 6 handoffs: 40 min, 59 min, never started (cancelled), 2.5 min, 4 min and 15 min.