Worktree branched from local `main` instead of `origin/main` when the session is rooted inside a git submodule (desktop app)

Status Open
Reported on v2.1.260
Maintainer reply None cached
Activity 0 comments · opened Sep 11, 2026

What's Wrong?

Starting a worktree session from the desktop app with the session rooted inside a git submodule branches the new worktree from the local main ref instead of refs/remotes/origin/main, and does not fetch first. If local main is stale, the session silently starts on old code.

Measured: a session started on a month-old base, 204 commits behind origin/main.

Two things narrow it down:

  • The CLI does not have this problem, on an older version — so this is not "an old build that's already fixed", the two surfaces behave differently.
  • The same desktop app is correct when the session is rooted at the superproject. Only the nested-repo case is wrong.

The reflog spelling differs too — the desktop app records a raw SHA, the CLI records a ref name — which suggests the base is resolved through different code paths.

worktree.baseRef is unset everywhere, so the documented fresh default should apply (branch from origin/<default-branch>, fetching first if not fetched in 24h).

What Should Happen?

Created from refs/remotes/origin/main — matching the documented fresh default, and matching what the same app does when rooted at the superproject.

Steps to Reproduce

  1. Have a superproject with git submodules.
  2. In one submodule, leave the checkout on a non-main branch, and let its local main fall behind origin/main.
  3. Start a worktree session from the desktop app with cwd set to that submodule.
  4. In the new worktree, run:

``
git reflog show $(git rev-parse --abbrev-ref HEAD) | tail -1
``

  1. Repeat with the CLI: cd <submodule> && claude --worktree

Error Messages/Logs

Refs in the submodule at the time of the test (all three distinct):

origin/main   a8cef9307a
main          f84446c12d   <- 204 commits behind origin/main, dated 2026-08-10
HEAD          446c96d749   <- the parked feature branch

Desktop app 2.1.260, rooted in the submodule — branched from local main, one month stale, recorded as a raw SHA:

branch: Created from f84446c12d9b6ddee03a4d739bd5f56ce6b90fc4

CLI 2.1.220, claude --worktree from the same directory, same moment — correct, recorded as a ref name:

branch: Created from origin/main

Desktop app, same version, rooted at the superproject instead — correct:

branch: Created from refs/remotes/origin/main

Possibly a second variant

Three days earlier, the same desktop version, in the same submodule, a session spawned via a task chip produced:

branch: Created from HEAD

That branched from the parked feature branch — 753 commits behind, and carrying 4 commits from an unrelated PR. Local main already existed at f84446c12d on that date, so a missing-local-main fallback doesn't explain it. There may be two distinct paths; including it in case they share a root cause.

Impact

Silent. Nothing in the session indicates the base is old, so the agent reads month-old files, treats them as current, and reasons from them. In our case that cost ~45 minutes before anyone noticed the code being discussed no longer existed.

Claude Code Version

Desktop app 2.1.260 (affected) / CLI 2.1.220 (not affected)

Is this a regression?

Unknown — first noticed on 2.1.260. The older CLI build (2.1.220) is correct, but that's a different surface, so it doesn't establish a working desktop version.

Operating System

macOS

View original on GitHub ↗