Repository navigation
[Bug]: t3_worktree_handoff never runs the project setup script (call interrupted when the session detaches) #21953
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Configure a project script with
runOnWorktreeCreate: true(ours copies untracked.env*files from the main checkout and runsbun install). - In a Claude thread attached to the project root, have the agent call
t3_worktree_handoffwithbranch,baseRef,startFromOrigin: trueand acontinuationPrompt(norunSetupScript, so it defaults totrue). - Let the continuation turn start in the new worktree.
Expected behavior
The project's setup script runs in the new worktree, as it does for worktrees created from the UI or via t3_thread_launch with a workspaceStrategy.
Actual behavior
The setup script never runs: no terminal is started, no .env* file is copied, and node_modules is absent until the agent runs bun install itself.
The t3_worktree_handoff tool call never completes. Its turn-item stays running from the handoff (12:51:29Z) until it is marked cancelled three hours later (15:50:28Z, run.background-work-cancelled). Meanwhile:
- 12:51:31.019Z
thread.metadata-updated(worktree bound) andprovider-session.detachedwith reasonWorkspace changed. - 12:51:31.042Z: the first run's attempt is marked
failed. - 12:51:31.053Z: the continuation run is created and starts normally in the worktree.
In WorktreeMcpService.performHandoff, the setup script runs after recheckAndBind and queueContinuation. Binding the thread to the worktree detaches the calling provider session. That appears to interrupt the MCP call before it reaches setupScriptRunner.runForThread, so the step is silently skipped. Running the setup script before the bind, or forking it detached from the calling session, would avoid this.
Related but distinct: #16520 (the continuation stream closing after handoff), which is fixed in this build: the continuation does run.
Impact
Major degradation or frequent failure
Version or commit
T3 Code (Beta) 0.1.0 desktop, server 0.1.0
Environment
macOS 26 (Darwin 25.6), Claude Code 2.1.304, provider claudeAgent (claude-opus-5-5)
Logs or stack traces
# orchestration_events for the thread, tool call toolu_01Sras…
2026-10-19T12:51:29.352Z turn-item.updated dynamic_tool mcp__t3-code__t3_worktree_handoff status=running
2026-10-19T12:51:31.019Z provider-session.detached reason="Workspace changed."
2026-10-19T12:51:31.042Z run-attempt.updated status=failed (run ordinal 1)
2026-10-19T12:51:31.053Z run.created (continuation, cwd=<worktree>)
2026-10-19T15:50:28.983Z turn-item.updated mcp__t3-code__t3_worktree_handoff status=cancelled
2026-10-19T15:50:28.983Z run.background-work-cancelledNo terminal and no setup-script event in between.
Workaround
A Claude Code SessionStart hook with matcher startup|resume that runs the same setup script. The continuation resumes the provider session (SessionStart:resume), so a startup-only hook does not fire either.
Activity
juliusmarminge commentedon Oct 19, 2026
Note
Grok responding on behalf of Julius.
Thanks for the event timeline. The symptom is clear, but the cause you suggested doesn't match the code.
Everything from the moment the worktree is created through the binding, the queued continuation and the setup script launch runs as one uninterruptible step. The comment there names the session detach case specifically (
apps/server/src/mcp/WorktreeMcpService.ts:229-237,:350-382). The same guard was already in 0.1.0. So the detach shouldn't be able to cut the call off before the setup script. A tool call that stays running for three hours points more to one of those steps waiting and never returning.Could you share the server trace spans for that handoff, especially anything under
WorktreeMcpService.performHandoffand the setup script runner, plus any "worktree handoff setup script failed" log line? That would show which step it stopped in.For now, your session start hook that runs the same setup is a reasonable workaround.
colinux commentedon Oct 19, 2026
Thanks, you're right: the detach theory was wrong, sorry for the noise. I reproduced it with traces this time.
A fresh
t3_worktree_handoff(branchonly) completed in 1.8 s.performHandoff→ProjectSetupScriptRunner.runForThreadsucceeded in 24 ms, but the tool result reportedsetupScript: { status: "no-script" }, and no terminal was opened.The cause is on my side, in how the scripts are resolved. My server settings have
projectSettingsFolded: true,defaultProjectScripts: null, and nodefaultProjectScriptsunderprojectSettingsOverridesfor this project. SoresolveProjectScriptsreturns the (empty) defaults, while the project record still carries the script withrunOnWorktreeCreate: true(visible throught3_project_list). The handoff isn't at fault.That leaves one question, which may deserve its own issue: should the settings fold have carried
project.scriptsover intoprojectSettingsOverrides[projectId].defaultProjectScripts? As it stands, a project's setup script silently stops running after the fold. Happy to close this one if that's expected and I just need to re-save the scripts in settings.The original three-hour "running" tool call from yesterday is a separate symptom I can't trace anymore (logs rotated).
juliusmarminge commentedon Oct 21, 2026
The traced follow-up matches #14991: with
projectSettingsFolded: true, setup returnsno-scriptwhen the action exists only on the project record and no effective settings override supplies it. That issue also has reports of worktree setup silently skipping for this configuration. Closing as a duplicate of that setup-script bug.The original session-detach explanation was retracted in the follow-up. The separate three-hour running call has no retained trace; if it recurs, please file it separately with fresh server traces. No new runtime reproduction was performed for this duplicate triage.