[Bug]: Sidebar thread label keeps the branch stamped at thread creation after the session switches worktree and branch#11078

Triage

Confirmed on current main. The sidebar is showing the creation-time stamp, not the session’s live worktree/branch. Desktop is just hosting the web UI — this is not an apps/desktop-only bug.

What the row uses

• Branch label / tooltip / search row render persisted thread.branch (apps/web/src/components/Sidebar.tsx). Same stamp is used in the command palette and the mobile thread list.
• Git status for that row is thread.worktreePath ?? project.workspaceRoot, not the provider session cwd.
• The “checked out on another branch” warning only runs for local threads and compares the stamp to the main repo (resolveLocalCheckoutBranchMismatch). An EnterWorktree into .claude/worktrees/… does not trip it, so the row never looks historical.
• The MR badge is the same stamp path: useLinkedThreadPullRequest reads persisted linkedPullRequest / branchPullRequest / pullRequests, and ThreadPullRequestReactor looks up by thread.branch. Local threads also keep a merged/closed PR after the lookup goes empty. That matches !164 surviving merge + deleted remote.

Why the existing follow-up missed this repro

followWorktreeBranchDrift (apps/server/src/orchestration/Layers/CheckpointReactor.ts) does persist a dedicated worktree’s new HEAD at turn end. It refuses when worktreePath is null, when the worktree is shared, or when HEAD is detached / a temporary t3code/<hex> branch.

This thread started on the main checkout (worktreePath === null), then the agent used Claude’s EnterWorktree into an existing .claude/worktrees/… path and checked out main. T3 has no EnterWorktree handler and does not write that cwd back onto the thread. Drift-follow therefore never runs. #5159 / #4831 fixed the dedicated-worktree case only.

Both the sidebar and the thread toolbar query the persisted cwd, so this is not the “toolbar live / sidebar stale” split #8126 described. The live location in the report is the agent shell (pwd / git rev-parse).

Not a duplicate of

• #4831 (closed; dedicated-worktree sync only)
• #8126 (closed unmerged; display-only, missing shared/temp guards, would desync the PR badge)
• #7409 (terminal checkout not refreshing UI)
• #8204 (stale diff base)
• #8209 (wrong PR for a non-default upstream)

Fix direction

Do not revive #8126 as the primary fix. Persist location on the server when the session cwd moves into a dedicated worktree, with the existing shared / detached / temp-branch guards. If the session is on a shared worktree (likely here — home-screen-figma-design-8d2b90 looks like another session’s tree), do not adopt that HEAD as thread.branch; at minimum stop asserting the old branch and its MR as current.

Leaving this open as an accepted bug.

@juliusmarminge Same root cause, second symptom: the stale worktreePath also breaks file previews on desktop and mobile, beyond the sidebar label and MR badge.

Setup: T3 Code desktop 0.0.41-nightly.20260910.1507, macOS 26 arm64, Claude session on a local thread in the main checkout.

Repro:

1. Claude calls EnterWorktree, and its cwd moves to <repo>/.claude/worktrees/<name>. The agent writes docs/plans/<plan>.md inside the worktree.

2. The turn completes. The thread's worktreePath stays null and branch stays main.

3. Opening that file from the chat fails:

   ProjectReadFileError: Failed to read workspace file 'docs/plans/.md' in ''. cause: WorkspaceFileSystemOperationError: operation 'realpath-target' failed at '/docs/plans/.md'

The file previews use the same thread.worktreePath ?? project.workspaceRoot cwd as the sidebar git status (web useActiveProjectTarget.ts, mobile ThreadFilesRouteScreen.tsx). So every relative file the agent creates in the worktree is unreadable from the thread. Persisting the location on the server, as the triage above proposes, should fix this symptom too.

Two points the fix direction may want to cover:

• Mid-turn reads. A turn-end sync still leaves files unreadable until the turn finishes.
• Providers without EnterWorktree hooks (Codex, OpenCode, and others). These agents usually run git worktree add <path> and then work there with chained commands such as cd <path> && .... Every provider already emits command_execution and file_change items. At turn end, the server could match the turn's command cwds and changed file paths against git worktree list, then adopt the worktree through the same guarded sync. Changed file paths look like stronger evidence than parsing cd, because each shell call can start fresh and git -C or absolute paths skip cd entirely.

More detail on the open PR: https://github.com/pingdotgg/t3code/pull/11086#issuecomment-5629654760

Filed via t3 triage by Claude Code (claude-opus-5).

Still reproduces on 0.0.46-nightly.20261013.3042 (macOS 27, Claude agent). This is the simpler "branch switch in place" case that #15989 covers. No EnterWorktree is involved.

1. Start a thread in a new worktree. T3 creates t3/<hex> and auto-renames it to a generated name, e.g. chore/run-branch.
2. Later in the thread, the agent runs git checkout <existing-feature-branch> in that same worktree.
3. The sidebar keeps showing chore/run-branch across later turns. The worktree's reflog shows the checkout, and git branch --show-current returns the feature branch.

It's common in practice. 25 active threads on 4 worktrees on my machine show the wrong branch, all from this pattern: T3 creates a new branch, then the agent switches to the branch the work is really on. The stale branch also points PR status refresh and merged-worktree cleanup (#16559, #17813) at the wrong branch. Happy to test #15989 once it's rebased.

Existing fix: #15989 explicitly covers this report, including native Claude EnterWorktree/ExitWorktree moves and persistent branch/worktree reconciliation. It remains open pending human approval. No duplicate PR opened; leaving this issue open for that fix.

Checked the existing fix #15989 at f5a8065: all 30 reported checks pass. Added the bugfix label. Preserved the ongoing maintainer work; no competing PR or merge. The PR still needs human approval and explicitly marks current-head live-provider proof as unproven. No fresh runtime reproduction was performed in this pass; leaving this issue open for the existing fix.