fix(server): a thread's branch and worktree follow the agent when it moves#15989

🟡 Medium orchestration-v2/ThreadLaunchService.ts:445

When the agent switches branches during the first turn, the thread can remain recorded with the generated branch instead of the branch actually checked out. expectedBranch and expectedWorktreePath only guard the metadata dispatch; git.renameBranch still renames oldBranch by name, and a rename dispatch can commit after followBranchDrift reads the stale projection, causing its guarded correction to be dropped with no later retry. Serialize these updates or re-check the live checkout before renaming or committing the rename metadata.

Fixed in 30d4195a41. The rename now re-checks the worktree's checked-out branch right before renaming. If it's no longer the temp branch, both the git rename and the metadata dispatch are skipped. A new test confirms renameBranch isn't called once the branch has moved.

🟡 Medium orchestration-v2/RunFinalizationService.ts:277

Switching a dedicated worktree to the repository default branch leaves the thread stamped with its old feature branch, so branch drift is not reconciled. refresh returns on local.isDefaultRef before reaching thread.branch !== local.refName; move that early return after drift reconciliation and before the pull-request refresh.

Fixed in a28254eac0. The default-ref early return now comes after drift reconciliation and before the PR refresh, so switching a dedicated worktree to the default branch updates the stamp. A new test covers it.

🟠 High src/orchestrationV2.ts:2630

A client can set preserveProviderSession: true on thread.metadata.update, causing a worktree change to skip the normal provider-session detach. The provider then keeps using the old cwd while the thread records the new worktreePath, so a user-initiated handoff can continue agent work in the previous worktree; keep this server-only flag out of the client command schema or strip/reject it at the RPC boundary.

Fixed in 9e08f00007. You're right: thread.metadata.update is also the wire schema for the client dispatchCommand RPC. ThreadMessageIntake.dispatchCommand now strips preserveProviderSession before the command reaches the orchestrator, so only the server's own turn-end follow can set it. There's a test for a client-sent command.

🟡 Medium orchestration-v2/ProjectionStore.ts:4522

Concurrent thread completions can both adopt the same previously unrecorded worktree, leaving two active threads claiming the same worktree/branch. hasSiblingThreadWithWorktreePath is only a standalone read, while Orchestrator.dispatch serializes by command.threadId; separate threads can both pass this predicate before either thread.metadata-updated projection commits. Coordinate this check with the update using a shared worktree lock or an atomic guarded write.

This one is real but narrow, and I left it as is (94bbbbdd0e documents it in place). The orchestrator serializes per thread, so two different threads can both pass the exclusivity read before either commits. Closing it would need a second lock keyed by worktree path, ordered against the per-thread lock. The worst case is a branch label shown on two threads until the next branch or location change corrects it.

🟡 Medium Adapters/ClaudeAdapterV2.ts:7013

Subagent EnterWorktree/ExitWorktree events are treated as root-session events, so their cwd updates the parent thread to the subagent's unrelated worktree and leaves branch/location and file previews incorrect. agent_id is not present on PostToolUse in SDK 0.3.276; use a root/subagent signal available on this hook path, or skip these hook events.

No longer relevant as of 916171bfc88057c72f0b8e7efc77c963d8fd3478

Not a bug as far as I can see. In the installed @anthropic-ai/claude-agent-sdk 0.3.276, agent_id is on BaseHookInput, so every hook including PostToolUse has it, and the SDK's doc comment says to use it to tell subagents from the root session. sdk.mjs passes it through unchanged from the CLI. parent_tool_use_id isn't on this hook input. ec525cc945 adds a comment with this evidence.

orchestration-v2/RunFinalizationService.ts:101

Cause.pretty(cause) puts arbitrary defect text and stacks into a log annotation, which may include command output or credentials. Please log a bounded failure category here and retain the underlying cause only in the error chain; avoid rendering it into metadata.

No longer relevant as of 30d4195a41a672e45078fdc106b625eac7544a9a

Fixed in 18d5b7a9d1. The new log annotations now record a bounded failure category (the error's _tag or name), following remoteRefreshFailureDiagnostics in VcsStatusBroadcaster.ts. The raw message and stack are no longer annotated.

error.message is arbitrary failure text and is not safe or bounded as a log annotation. The new detail annotations here and in the worktree-move status and dispatch catches have the same issue; please replace them with normalized failure categories while keeping the original error as the cause where needed.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 18d5b7a9d1. The new log annotations now record a bounded failure category (the error's _tag or name), following remoteRefreshFailureDiagnostics in VcsStatusBroadcaster.ts. The raw message and stack are no longer annotated.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Invalidate cached PR metadata when the worktree ref changes.

When followBranchDrift adopts local.refName, the status cache can pair the new local refName with the previous remote pr. The toolbar’s branch guard compares the new refName with the new branch, so it can accept that stale PR. If the thread has no linked PR, the toolbar can show and open the previous branch’s MR under the new branch. Do not use cached PR status as the branch fallback until it is known to match the current ref.

✅ Confirmed as addressed by @shivamhwp

Fixed in f90049b194. After a branch follow, the observer now calls refreshPullRequestStatus for that cwd, default branch included. It re-resolves the PR for the branch that's checked out, so the cache no longer pairs the new branch with the previous branch's PR. The drift tests now assert the PR refresh runs after a follow, and only then.

@shivamhwp Thanks for the fix. The updated observer calls refreshPullRequestStatus(cwd) after a branch follow, including a switch to the default branch. This addresses the stale PR metadata finding.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

You are interacting with an AI system.

🟡 Medium orchestration-v2/RunFinalizationService.ts:236

Finalizing a thread that shares a provider session can overwrite its worktreePath with another thread's cwd and adopt that worktree's branch, even though this thread's agent never moved. getThreadProviderContext returns all bound sessions, including shared sessions whose cwd is where another thread opened them, so choosing the newest session at line 236 does not identify the current turn's cwd. Restrict this lookup to the session/run owned by the finalized turn before dispatching thread.metadata.update.

Fixed in f90049b194. The follow now reads the session of the thread's active provider thread (activeProviderThreadId to providerSessionId), not the newest session bound to the thread. If that session is also bound to another thread, it skips the follow, since one shared cwd can't say whose move it was. That uses a new ProjectionStoreV2.isProviderSessionShared, with SQL and in-memory versions. Tests cover a newer session bound elsewhere and a shared session.

🟡 Medium orchestration-v2/RunFinalizationService.ts:123

After EnterWorktree moves a run into a dedicated worktree, finalize records that worktree and then overwrites its branch with main from the original checkpoint cwd, leaving the thread pointing at the wrong branch. Move followWorktreeMove after the checkpoint-cwd refresh so the new worktree's feature branch is recorded last.

Fixed in f90049b194, with a guard instead of reordering. Branch drift is only followed when the refreshed cwd is the thread's own worktreePath. Right after followWorktreeMove, the checkpoint cwd is where the thread was, so its branch is ignored. This also holds if the two steps ever swap order. A new drift case covers it: a thread already moved to .claude/worktrees/feature, refreshed at /repo on main, dispatches nothing.

followWorktreeMove wraps projection, project, and other lookup failures in one RunFinalizationRefreshError with the placeholder cwd "<session>". This loses the failing operation and reports a non-path as the resource. Please map each failing read at its boundary with its operation and actual thread/project identifier, retaining the immediate error as cause; update the observer's error type if needed. This needs changes at multiple boundaries, so no single-hunk fix applies.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in a51d325a01. followWorktreeMove now fails with a RunFinalizationFollowError that names the operation (read-thread, read-provider-context, read-session-sharing, read-project), the thread id, and the project id for the project read, and keeps the underlying error as cause. The "" placeholder is gone.

🟡 Medium Adapters/ClaudeAdapterV2.ts:3335

After EnterWorktree or ExitWorktree, the emitted session update contains the new cwd, but entry.runtime.providerSession remains the original snapshot. ProviderSessionManager.writeReleasedSessionEvents then persists that stale cwd on release, shutdown, or runtime error, losing the worktree move; keep the runtime session snapshot synchronized with this update.

Fixed in 5601d381c4, in ProviderSessionManager rather than the adapter. The manager's spread of the runtime would freeze any adapter-side getter anyway. The live entry now keeps the latest session reported through provider_session.updated, and attach and release write that one. A new test, "releases a session at the cwd it last reported", fails without the fix.

🟡 Medium src/server.ts:505

Normal run termination calls the default no-op refreshAfterTurn, so the production project-wide PR refresh never runs and PR statuses remain stale. This provision constructs and memoizes the RunExecutionService before the observer is available, causing it to capture the no-op observer; restructure the layer wiring so the production observer is provided before that service is constructed.

Confirmed and fixed in a51d325a01. RunExecutionService only needs refreshAfterTurn, so that moved to its own RunTurnObserver reference. server.ts provides it outermost, so it is in context before the finalization observer builds the orchestrator (and RunExecutionService with it). RunFinalizationObserver no longer carries refreshAfterTurn. RunFinalizationService itself is only built under the effect worker, after the observer exists, so it still gets the real one.

🟠 High orchestration-v2/RunFinalizationService.ts:222

After followWorktreeMove records branch: null for a detached-HEAD or temporary-branch worktree, checking out a valid branch in that same worktree leaves the thread branchless. followBranchDrift rejects the update because this guard requires a non-null current branch; allow the exclusive compare-and-swap to adopt from null too.

Fixed in cb076db3d8, as suggested. A null branch now follows, still under requireExclusiveWorktree, so a shared worktree never hands its branch to a thread. The old test "does not invent a branch for a thread that never had one recorded" is now "adopts a branch for a dedicated worktree thread recorded without one", and it expects the dispatch with expectedBranch: null.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Reset the tracked cwd when a new Claude query process opens.

trackedCwd lives for the whole adapter session. A new CLI process does not reset it. openQuery can close one process and start another without closing the adapter session. Examples are a selection change that cannot apply live, a query-policy change, or a process that exits after a failed turn. The new process starts at turnInput.runtimePolicy.cwd. trackedCwd and the persisted provider session still report the location the old process moved to, together with its cwdChangeSource.

Consequence:

1. A turn fails after EnterWorktree. Failed runs do not enqueue checkpoint capture, so followWorktreeMove does not run.
2. The next turn opens a fresh process at the recorded checkout. The agent does not move.
3. At finalization, session.cwd is still the worktree and session.cwdChangeSource === recordedCwd. RunFinalizationService.followWorktreeMove then moves the thread into a worktree that the live process never entered.

A related problem also occurs. If the new process then runs EnterWorktree into the same path, nextCwd === previousCwd, so no update is emitted.

Fix: after queryRunner.open succeeds, compare the opened cwd with trackedCwd. If they differ, set trackedCwd to the opened cwd and emit provider_session.updated with that cwd and no cwdChangeSource.

✅ Confirmed as addressed by @juliusmarminge

Fixed in 42590b7bf7. After a fresh query opens successfully, the adapter reconciles its tracked cwd with the opened cwd and emits a session update with the old move source explicitly cleared. This happens before turn handling. Live-query reuse and continuation returns are unchanged, so a failed turn can still catch up in the same live process.

The adapter lifecycle control reproduces both failures on the prior head: no reset after process replacement, and a suppressed repeated native Enter. Both replacement and reuse variants now pass, along with all 645 focused tests and scoped checks. Two fresh independent whole-PR reviews returned no findings. The shared detach-reason constant also addresses the review-summary nit without changing persisted text.

Fresh actual server/CLI proof covers 13 Claude turns and the Codex sole-binding scenario; the failed-turn replacement itself is verified at the SDK adapter boundary, not through a forced live provider failure. Current-head evidence. CI and configured bot review on this new head are pending; leaving unmerged for human approval.

@juliusmarminge The supplied code confirms the fix. After queryRunner.open succeeds, openQuery resets a different trackedCwd and emits provider_session.updated with cwdChangeSource: undefined before turn handling.

Live-query reuse and continuation returns remain unchanged. This addresses the stale cwd and suppressed repeated EnterWorktree cases. I have not independently run the reported tests or live-provider checks.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

You are interacting with an AI system.