Repository navigation
[Bug]: Stale "Waiting on background task T3 Worktree Handoff" banner persists after a Claude worktree handoff #15993
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks for the thorough write-up, @letrandat. Your projection snapshot matches current
main(cf3e714b0f), and0.0.46-nightly.20261004.2657isn't missing a fix.What I found
t3_worktree_handoffrebinds the thread and schedulesprovider-session.detach. Claude sessions are exclusive, so that detach releases the whole session.releaseEntryfails every event subscriber withProviderAdapterEventStreamErrorbefore it closes the adapter, and the run is stored as failed with "The provider event stream closed unexpectedly…".finalizeActiveTurndoes cancel open tool calls, but it runs while the session scope is closing, after those subscribers are gone, so the cancellation never reaches the run. Run finalization only closes open subagent rows, sodynamic_toolandcommand_executionitems stayrunning.A later run doesn't adopt them either. Inheritance requires the same provider thread, and the released Claude session no longer exists. Meanwhile
pendingBackgroundTurnItemsstill lists any active command, dynamic tool, or subagent whose run isn'trolled_back. So once a later turn settles, the composer shows Waiting on background task … for the handoff item. Stop works from the same list and marks items on a dead provider session asinterrupted, which is why it clears the banner even though nothing is running.The two outcomes depend on timing. If the Claude process exits first,
finalizeActiveTurncan publish the cancellation while subscribers are still attached, and the item endscancelled(what #15136 recorded). If the detach releases the session first, the cancellation is dropped and the item staysrunning, which is what you're seeing. The same leftover can happen whenever an exclusive session is released while a command or dynamic tool is still running.#15136 is the same detach recorded as an unexpected stream close. Open PR #15203 turns a planned workspace detach into an interruption so the continuation can start, but it leaves in-flight
dynamic_toolandcommand_executionrows alone, so this banner could still appear with that change.Workaround: press Stop on the banner. That settles the leftover items on the dead session, though it doesn't revive the handoff.
Likely fix area
RunExecutionService/ run finalization. One option is to terminalize opendynamic_toolandcommand_executionrows when a run settles, the same way subagent rows are handled.releaseEntry/finalizeActiveTurnordering. Another option is to publish the tool cancellations before failing subscribers on an exclusive-session release.packages/shared/src/orchestrationV2PendingBackgroundWork.ts(pendingBackgroundTurnItems). A third option is to skip items whose provider session is already gone.
A maintainer will decide on the fix direction.
- addedbugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.via-triageFiled through npx t3 triageFiled through npx t3 triage
on Oct 5, 2026 Additional reproduction on macOS desktop connected to a remote Linux server (
0.0.46-nightly.20261007.2774), using Claude Sonnet 5.5 in Full access mode.The same stale-task pattern occurs, but the suggested Stop workaround does not clear it:
- The composer shows Waiting on 2 background tasks:
advisor,mcp__t3-code__t3_worktree_handoff. - Thread activity records both as
dynamic_toolitems still markedrunning. - Run 3 failed with "The provider event stream closed unexpectedly." The handoff continuation (run 4) was cancelled; runs 5–8 subsequently completed. The thread has no active run, but those two tool items remain pending.
- Clicking Stop briefly changes the button to Stopping..., then it returns to Stop with both tasks still listed. This was reproduced directly in the macOS UI.
The worktree handoff did take effect and later turns ran there, so this appears to be stale tool state after the failed handoff. The additional issue is that Stop fails to settle the leftover items in this case.
- The composer shows Waiting on 2 background tasks:
Before submitting
Area
apps/server
Steps to reproduce
claudeAgent/claude-opus-5-5thread (full access), have the agent callt3_worktree_handoffwith acontinuationPrompt(startFromOrigin: true,runSetupScript: false).Expected behavior
Once the handoff's turn ends, its tool item is settled, and the composer shows no pending work after later turns complete.
Actual behavior
The composer keeps showing "Waiting on background task T3 Worktree Handoff" with a Stop button, after 7 later turns that all completed normally. The agent has nothing running. When asked what it was waiting for, it confirmed the handoff had finished long before.
From the thread's projection (read from a copy of the state DB):
failedtool_usecancelledcompletedThe
dynamic_toolturn item formcp__t3-code__t3_worktree_handoffin run 1 is stillstatus: "running"withcompletedAt: null. Nothing will ever complete it, because the Claude session that owned it was released by the workspace-change detach.Two pieces combine:
RunExecutionServicecloses open run-owned subagent rows (L687), but deliberately leavesdynamic_toolandcommand_executionitems open so a late completion can arrive (L93-L101). That holds while the provider process is alive. Here the session was released, so the item staysrunningforever.pendingBackgroundTurnItems(L178-L195) lists any active background-type item from any run that is notrolled_back, so the orphan from failed run 1 shows up again every time a later run settles.This is related to #15136, which has the same trigger: the planned detach on handoff is treated as an unexpected stream close for Claude. There, the handoff item ended
cancelledand the continuation stayed held. Here, the continuation was cancelled, later turns ran fine, and the handoff item was never settled. That suggests the item cleanup on detach is racy, and #15203 may not cover it because it changes how the detach ends the turn, not what happens to in-flight tool items. The same leftover probably appears whenever a session is released while a tool item is in flight. A quick scan of the same DB found 3 other threads withcommand_executionitems stillrunningfrom older runs.Pressing Stop is the only way out, and it targets work that no longer exists.
Impact
Minor bug or occasional failure
Version or commit
0.0.46-nightly.20261004.2657
Environment
macOS, desktop app, local server,
claudeAgent/claude-opus-5-5, full accessLogs or stack traces
Filed by Claude Opus 5.5, running in T3 Code through the Claude Code harness, on behalf of @letrandat.