[Bug]: Successful Codex worktree handoff is shown as stopped and interrupted by user#24513
Before submitting
- I searched existing issues and did not find an exact duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web (handoff activity and run status; underlying classification may involve apps/server)
Steps to reproduce
- In a Codex thread attached to a main checkout, ask the agent to work on a task in a Git worktree.
- Have the agent call
t3_worktree_handoffwith a new branch, an absolute sibling worktree path,baseRef: "dev",startFromOrigin: true,runSetupScript: false, and acontinuationPrompt. - Do not press Stop or otherwise interrupt the turn.
- Let the automatic continuation start in the new worktree, then inspect the previous turn's tool activity and status.
Observed once on October 24, 2026, around 12:36 PM America/Chicago. Repeatability has not been established.
Expected behavior
A successful worktree handoff should settle as a successful transition, with language such as “Moved thread to worktree” and “Continuing in new workspace.”
If ending the old provider session is necessary for the move, that intentional system transition should not be attributed to the user or presented as a failed/stopped handoff.
Actual behavior
The timeline shows:
- “Stopped handing off thread to a git worktree”
- Red status: “Run interrupted · Run interrupted by user”
- The tool result received by the agent says “aborted by user after 2.7s”.
The user did not interrupt anything and asked why the handoff had failed. In fact, the new worktree was created, the thread moved into it, the queued continuation ran automatically, and shared-database setup completed successfully.
A subsequent t3_worktree_status call confirmed attached: true, the requested worktree/branch, and the original checkout as projectWorkspaceRoot. The shell cwd and Git branch also matched the requested task worktree.
The issue is the misleading status and attribution: the user sees an apparent failure even though the transition succeeded. The exact internal cause has not been verified.
Impact
Minor bug or occasional failure. Causes users to distrust a successful handoff and consider retrying an operation that already created its worktree and branch.
Version or commit
Not captured. Observed October 24, 2026.
Environment
Linux (Omarchy), T3 Code with the Codex harness, gpt-6.1-sol, high reasoning effort. Thread starts in the main checkout and moves to a sibling Git worktree.
Logs or stack traces
| 1 | Handoff activity: Stopped handing off thread to a git worktree |
| 2 | Run status: Run interrupted · Run interrupted by user |
| 3 | Tool result: aborted by user after 2.7s |
| 4 | Later t3_worktree_status: attached=true; requested branch and worktree path |
| 5 | Continuation: ran automatically in the new worktree; npm run setup completed |
Related reports
#15993 describes a stale pending-work banner after a successful Claude handoff. This report concerns Codex displaying a stopped handoff and falsely attributing the planned transition to user interruption; the continuation succeeds.
Workaround
Verify the actual binding with t3_worktree_status and the current Git branch before retrying. In this occurrence, no retry was needed.