Reproduced in the web dev app on ed9b7ca9c5, Linux/Chromium. Created a repository with two branches differing in one tracked file, left a conflicting edit on main, opened New thread with Current checkout, and selected the other branch. The notification says “Failed to switch ref” and “git checkout failed,” without explaining the conflicting local edit. Git preserved the branch and local changes. No duplicate or existing fix found among the open issues and PRs.
[Bug]: Explain checkout failures caused by uncommitted changes when creating a thread#7928
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web, apps/desktop
Steps to reproduce
- Open T3 Code on a repository using the current checkout (rather than a separate worktree).
- Make changes that remain uncommitted and that would be overwritten by switching to the branch/ref for a new thread.
- Create a new chat thread.
- T3 attempts to switch the repository ref with
git checkout.
Expected behavior
T3 should surface a clear, actionable error, for example:
Git checkout failed because the current branch has uncommitted changes that would be overwritten. Commit, stash, or discard those changes before creating a new thread.
The message should identify this as a normal Git safety check rather than an unexplained T3 failure.
Actual behavior
The UI displays a generic notification:
Failed to switch ref.
Git command failed in
GitVcsDriver.switchRef.checkout(...): git checkout failed
This does not explain that uncommitted changes in the current local branch are the reason git checkout failed, nor what the user needs to do to proceed.
Impact
Major degradation or frequent failure
Version or commit
T3 Code desktop app (observed 2026-08-22; version not captured)
Environment
macOS; local Git checkout with uncommitted files.
Workaround
Commit, stash, or discard the pending working-tree changes before creating the thread.
Supporting screenshot
The observed notification showed only the generic GitVcsDriver.switchRef.checkout failure; the underlying Git reason was not shown.
Fix submitted in #23346. Conflicting tracked edits now produce commit/stash/discard guidance in the web app. The PR includes paired recordings for the composer and Details branch selectors; native macOS desktop and mobile remain unverified.
Still happens on 0.1.6-nightly.20261030.3917 (macOS arm64 desktop). Picking a branch in a new thread's draft, with 5 modified tracked files in the main checkout, gave GitVcsDriver.switchRef.checkout: git checkout failed.
In this tag, fallbackErrorDetail: "git checkout failed" in GitVcsDriverCore.ts replaces the detail from git's failure, so neither the trace nor the toast shows the reason. All 60 of the most recently updated local branches I compared differ from HEAD in those files. That points to the overwrite check, but the missing stderr means I can't confirm it.
The failure doesn't stop the send. With Auto balance on, the next message created the thread on another machine, in a new worktree from origin/main, after the checkout failure on the first.
Sent by Claude Opus 5.5 (Claude Code via t3 triage).
Still happens on stable v0.1.7 (T3 Code Desktop, macOS arm64, local server).
Repro: a repo's main checkout is on branch dev-speed with 5 modified tracked files. From the desktop app, switch the thread's branch (Current checkout) to main or codex-review. The popup says Git command failed in GitVcsDriver.switchRef.checkout (…): git checkout failed, with no reason given.
Evidence:
- In
server.trace.ndjson, theGitVcsDriver.switchRef.checkoutspan runscheckout <ref> --(3 args).switchRefthen fails withGitCommandErrorabout 16 ms later. Neither the trace nor the popup has git's error text. - All 5 modified files differ between HEAD and both target branches. So git's "local changes would be overwritten" check is almost certainly the cause. Git kept the branch and the edits.
fallbackErrorDetail: "git checkout failed"is still inapps/server/src/vcs/GitVcsDriverCore.tsonmaintoday (around line 4942), so this isn't fixed in nightlies yet.
Another case for #23346 to cover: one of the targets, codex-review, is also checked out in a linked worktree. git checkout fails there with "already used by worktree" even with a clean tree, and T3 Code shows the same generic message. It would help if the improved error also covered that case, ideally pointing the user to the existing worktree.
Workaround: stash or commit the changes before switching. For a branch that's checked out in another worktree, open that worktree instead.
Produced by Claude Opus 5.5 (claude-opus-5-5) via Claude Code, from a T3 Code triage session.