Add per-chat branch tracking and branch switch prompts

[taschaub]

What Changed

Adds per-chat branch tracking so each chat can stay associated with the git branch it belongs to.

This PR:

• stores the branch a chat is linked to
• auto-links older/unlinked chats to the current branch when they are opened
• shows the chat branch in the sidebar
• detects when the current checkout differs from the chat's linked branch
• offers actions to either checkout the chat branch or relink the chat to the current branch
• updates branch metadata when a feature branch is created through the git action flow
• adds focused tests for the branch tracking helpers

Why

Chats often represent work on a specific branch. If the user later switches branches and continues the same chat, the agent can accidentally run against the wrong checkout.

This makes the branch relationship explicit. It also gives the user a clear recovery path instead of silently changing chat metadata or letting the agent continue on the wrong branch.

UI Changes

This adds branch context in two places:

1. Sidebar thread rows now show the linked branch for each chat.

2. When the active checkout does not match the chat's branch, the composer shows a warning with actions to checkout the chat branch or relink the chat.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Add per-chat branch tracking and branch-mismatch banner in the composer

• Introduces useThreadBranchTracking hook that auto-links a server thread to the current git branch when the thread has none, and detects mismatches between the thread's stored branch and the active checkout.
• When a mismatch is detected, a warning banner appears in the composer with actions to either switch the working tree to the chat's branch (vcs.switchRef) or relink the chat to the current branch.
• Adds SidebarThreadBranchBadge to display each thread's associated branch in the sidebar row.
• Removes the previous resolveLiveThreadBranchUpdate auto-sync behavior from GitActionsControl; branch syncing now happens only via explicit user actions or the new banner.
• Behavioral Change: threads no longer silently auto-relink their branch on git status changes — users must act on the mismatch banner instead.

📊 Macroscope summarized 9f69ecd. 6 files reviewed, 4 issues evaluated, 0 issues filtered, 1 comment posted

🗂️ Filtered Issues

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 5ed3113c-e5b9-4d6b-9eca-0dd4dbbeaa03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

🟡 Medium chat/useThreadBranchTracking.tsx:117

In handleRelink, the optimistic setThreadBranch call at line 123 updates local state before the API call, but when the API fails (lines 132-139), the local state is never rolled back. The UI shows the chat relinked to the new branch while the error toast reports failure, leaving the user in an inconsistent state. Consider moving setThreadBranch after the successful API response, or rolling back local state in the catch block.

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/web/src/components/chat/useThreadBranchTracking.tsx around line 117:

In `handleRelink`, the optimistic `setThreadBranch` call at line 123 updates local state before the API call, but when the API fails (lines 132-139), the local state is never rolled back. The UI shows the chat relinked to the new branch while the error toast reports failure, leaving the user in an inconsistent state. Consider moving `setThreadBranch` after the successful API response, or rolling back local state in the catch block.

Evidence trail:
apps/web/src/components/chat/useThreadBranchTracking.tsx lines 117-145 (handleRelink function): setThreadBranch called at line ~123 before API call, catch block at lines ~132-139 shows toast only with no state rollback. apps/web/src/store.ts lines 1922-1944: setThreadBranch mutates Zustand store state (thread.branch, thread.worktreePath).

[macroscopeapp]

Approvability

Verdict: Needs human review

1 blocking correctness issue found. This PR introduces new user-facing behavior with branch mismatch banners and sidebar badges, replacing silent auto-relinking with explicit user prompts. Additionally, there is an unresolved review comment identifying a potential state consistency issue when API calls fail.

^{You can customize Macroscope's approvability policy. Learn more.}

[juliusmarminge]

Duplicate of #2284