Worktree creation fails: git worktree remove --force on non-existent path causes fatal error

[breskeby]

Bug

When creating a new worktree via the Supacode UI or supacode repo worktree-new, the operation always fails with "Git command failed" for repositories where no worktrees have been previously created under ~/.supacode/repos/<repo>/.

Root Cause

Before calling the bundled wt sw script to create a worktree, Supacode's Swift code runs a pre-cleanup step:

git -C <repo> worktree remove --force ~/.supacode/repos/<repo>/<branch>/

This fails with exit code 128 when the target path doesn't exist (which is always the case for a brand-new worktree):

fatal: '~/.supacode/repos/<repo>/<branch>/' is not a working tree

Supacode treats this as a fatal error and aborts — the wt sw command is never invoked.

How I diagnosed this

I enabled [trace2] eventTarget in ~/.gitconfig to capture all git commands Supacode executes. The sequence for every worktree creation attempt is:

1. git check-ref-format --branch <name> → exit 0 ✓
2. git rev-parse --is-bare-repository → exit 0 ✓
3. git worktree remove --force <target-path>/ → exit 128 ✗
4. Supacode aborts. wt sw is never called.

Running the wt sw command directly from a terminal works perfectly:

wt --base-dir ~/.supacode/repos/<repo>/ sw --from origin/main <branch>

Expected behavior

git worktree remove --force should be allowed to fail silently when the target path doesn't exist or isn't a registered worktree. It's a cleanup step — if there's nothing to clean up, that's fine.

Suggested fix

Either:

• Skip the worktree remove call if the target path doesn't exist
• Ignore exit code 128 from worktree remove when the error message contains "is not a working tree"

Reproduction

1. Add https://github.com/elastic/elasticsearch as a repository in Supacode (large repo, ~41,500 files, open source)
2. Try creating a new worktree from the UI with any branch name based on origin/main
3. Observe "Git command failed" error — the wt sw command is never executed

Environment

• Supacode v0.8.5 (build 136000)
• macOS 26.4 (25E246), Apple Silicon
• Git: Apple Git 2.50.1 (/Applications/Xcode.app/Contents/Developer/usr/bin/git)

[sbertix]

Hey 👋

Were you still cloning the repository when you tried creating the worktree, perhaps?

Cause, I'll be honest, the presented flow doesn't really match the code.
For starters it would mean it would fail for every new repo (which is not the case), but also cause the only call site for runGitWorktreeRemove is removeWorktree, and the only call sites for removeWorktree in the create flow are after a failure, in cleanupFailedWorktree. So the sequence is necessarily:

isValidBranchName → isBareRepository → … → wt sw (fails for some other reason) → cleanupFailedWorktree → worktree remove --force (exit 128, swallowed)

I was able to replicate this with a placeholder clone, though. Which makes sense with elasticsearch taking quite a long time to get locally. Could you double check that wasn't the issue?

cat <repo_path>/.git/HEAD  # not ref: refs/heads/.invalid
git -C <repo_path> rev-parse HEAD # not fatal: ambiguous argument 'HEAD'
git -C <repo_path> symbolic-ref refs/remotes/origin/HEAD # not (empty)
git -C <repo_path> rev-parse origin/main # not fatal: Needed a single revision

Cause after waiting for the cloning to end, it appears to work just fine for me, so we might need some more digging if it still fails your end 🥲

[breskeby]

No the cloning has finished long before as I checked it out before moving to supacode already. I wonder if it’s a combination of the size of the repository, the fact that I’m using https authentication and (just guessing) my default shell is Oh my zshell. In the UI when triggering the work tree creation I can see initially that folder being created and the fetch operation. Than a few seconds later I got the error and the work tree disappears in the overview again Sent from [Proton Mail](https://proton.me/mail/home) for iOS.

…

-------- Original Message --------

On Saturday, 05/09/26 at 00:08 Stefano Bertagno ***@***.***> wrote: sbertix left a comment [(supabitapp/supacode#304)](#304 (comment)) Hey 👋 Were you still cloning the repository when you tried creating the worktree, perhaps? Cause, I'll be honest, the presented flow doesn't really match the code. For starters it would mean it would fail for every new repo (which is not the case), but also cause the only call site for runGitWorktreeRemove is removeWorktree, and the only call sites for removeWorktree in the create flow are after a failure, in cleanupFailedWorktree. So the sequence is necessarily: isValidBranchName → isBareRepository → … → wt sw (fails for some other reason) → cleanupFailedWorktree → worktree remove --force (exit 128, swallowed) I was able to replicate this with a placeholder clone, though. Which makes sense with elasticsearch taking quite a long time to get locally. Could you double check that wasn't the issue? cat < repo_path > /.git/HEAD # not ref: refs/heads/.invalid git -C < repo_path > rev-parse HEAD # not fatal: ambiguous argument 'HEAD' git -C < repo_path > symbolic-ref refs/remotes/origin/HEAD # not (empty) git -C < repo_path > rev-parse origin/main # not fatal: Needed a single revision Cause after waiting for it to end, it works just fine 💪 — Reply to this email directly, [view it on GitHub](#304 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAS35GDVXYSDMLZV4HN3PT4ZZLFXAVCNFSM6AAAAACYWSAZPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMJQGE4TCMJUHE). You are receiving this because you authored the thread.Message ID: ***@***.***>

[sbertix]

Ok, let me dig into that a bit more, then 💪

Could you still let me know the output of these, just to have a bit more to work on?

cat <repo_path>/.git/HEAD  # not ref: refs/heads/.invalid
git -C <repo_path> rev-parse HEAD # not fatal: ambiguous argument 'HEAD'
git -C <repo_path> symbolic-ref refs/remotes/origin/HEAD # not (empty)
git -C <repo_path> rev-parse origin/main # not fatal: Needed a single revision