Operating system

macOS

Orca version

1.4.237 (macOS desktop app, worktree created on a remote Linux host over SSH; orca --version on the host reports 1.4.237)

Details

Short summary

Creating a worktree for a branch that exists only on the remote (origin/<branch>, no local ref) cannot be done from the Create Worktree dialog. Typing the branch name under Advanced → Branch name does not check that branch out: Orca silently creates a new branch with a -2 suffix cut from the repo base ref. There is no warning that the typed name was changed or that the remote branch was ignored.

What happened?

1. Project header → + (Create worktree). Host: remote SSH Linux machine.
2. Leave Branch from on the repo base ref (origin/develop).
3. Expand Advanced, set Branch name to a branch that exists on origin but has no local ref (e.g. feature/foo). The Reuse branch checkbox does not appear, as expected for remote-only refs.
4. Create.

Result: the worktree opens on a fresh branch (feature/foo-2) based on origin/develop, with none of the remote branch's commits. No toast or dialog explains that the requested name was not used.

Expected

Either of:

• Orca fetches origin/feature/foo and creates local feature/foo tracking it (what the docs promise for "An existing remote branch — Orca will fetch and check it out" on the Worktrees page), or
• the dialog refuses the name and says the branch exists on the remote, instead of quietly renaming it.

Why it happens (from a read of main)

In src/main/runtime/runtime-local-worktree-create-candidate.ts (same logic in src/main/ipc/worktree-remote.ts for SSH hosts):

• canCheckoutExistingLocalBranch only checks refs/heads/<branch>, so a remote-only branch is never eligible for reuse.
• getBranchConflictKind then reports 'remote' because origin/<branch> exists and the selected base ref is not that branch.
• A remote conflict just hits continue, so the loop bumps the suffix and creates <branch>-2. The WorktreeCreateCollisionError ("already exists on a remote") is only thrown if every suffix attempt fails, which never happens in practice.

The only way the explicit name resolves to the remote branch is when Branch from is set to exactly origin/<branch> as well, because buildRemoteBranchConflictRefs excludes allowedBaseRef. Nothing in the UI hints that both fields must agree.

Suggested fix

• When the explicit branch name (or the selected ref) matches a remote-only branch, create a local tracking branch from it instead of treating it as a conflict, or
• show the Reuse branch option for remote refs and have it fetch + track, and
• never silently suffix a name the user typed explicitly; surface the collision instead.

Related

• [Feature]: Create new worktree with existing branch #5181 / feat(worktree): reuse an existing branch when creating a worktree (#5181) #5781 added Reuse branch, but only for local branches.
• [Bug] How to switch to existing worktree in orca w/out creating a new one #9065 has an unanswered follow-up from Sep 2026 asking exactly this ("I have an existing branch in the remote, I want to open that branch inside a new worktree").
• [Bug]: worktree create appends spurious -N suffix when name only matches an unrelated refs/remotes/* ref #16646 covers a spurious -N suffix caused by refs/remotes/* matches.
• [Bug]: Worktree base-ref picker never fetches, so branches pushed since the last fetch are invisible with no signal #10516 covers the picker not fetching remote refs.
• [Feature]: orca worktree create --pr can check out the PR head branch, like the app's PR flow #31403 asks for the same capability from the CLI.

Workaround

Create it with git from the primary checkout and unhide non-Orca worktrees in the sidebar:

git fetch origin
git worktree add ../feature-foo feature/foo