fix: Recover from deleted cwd

[davidbeesley]

Follow up on #1109 #1146

I think #1146 has a bug where it won't work if there are multiple git repos in the parent dir (in my case ~/git).

Since wt has a good guess for the main repo location from its own configuration worktree-path, I think wt could try that route before giving up.

Also the UX is a bit off, I think it should only recommend wt switch ^ if it's resolvable.

[dave@scgtaranaki] [02/22/26 17:03:56.590] [🐏  84%] [~/git/accounting-rs.data] []
❯ wt switch                                                            
✗ fatal: Unable to read current working directory: No such file or directory                                                                  
↳ Current directory was removed. Try: wt switch ^

[dave@scgtaranaki] [02/22/26 17:03:59.867] [🐏  84%] [~/git/accounting-rs.data] []
❯ wt switch ^                                                          
✗ Failed to switch worktree                                            
  fatal: Unable to read current working directory: No such file or directory
↳ Current directory was removed. Try: wt switch ^

[dave@scgtaranaki] [02/22/26 17:04:05.106] [🐏  84%] [~/git/accounting-rs.data] []
❯ wt switch main
✗ Failed to switch worktree
  fatal: Unable to read current working directory: No such file or directory
↳ Current directory was removed. Try: wt switch ^

I had CC take a regex approach to reverse engineer using worktree-path with a fair amount of success for minimal effort if that route has any interest to you.

[max-sixty]

Since wt has a good guess for the main repo location from its own configuration worktree-path, I think wt could try that route before giving up.

ah, good idea!

Also the UX is a bit off, I think it should only recommend wt switch ^ if it's resolvable.

yes, that is bad, I didn't think enough about this one...

[max-sixty]

Since wt has a good guess for the main repo location from its own configuration worktree-path, I think wt could try that route before giving up.

ah, good idea!

actually, sorry, how do we get worktree-path, given the config is gone? or we're just guessing from pwd?

[davidbeesley]

how do we get worktree-path, given the config is gone? or we're just guessing from pwd?

Short answer: Use the user global config (~/.config/worktrunk/config.toml). I think user can override with env or something plus wt has a default config if none exists.

Long Answer

I had CC tackle this with regex reverse engineering the path. Seemed to work. Here is what CC did for me:

The worktree-path template is reverse-engineered into a regex and matched against $PWD. There are two kinds of template:

ParentTraversal (the default /../ template)

The default template {{ repo_path }}/../{{ repo }}.{{ branch | sanitize }} produces paths like /home/user/git/myrepo.feature-x after normalization (the /../ collapses). The regex becomes:

^(?P<parent>.+)/(?P<repo_branch>[^/]+)$

repo and branch are merged into one capture group because we can't split them with regex alone — the separator (.) might also appear in the repo name. For example given $PWD = /home/user/git/my.project.feature-x:

• parent captures /home/user/git
• repo_branch captures my.project.feature-x

To find where the repo name ends, we walk through each . position and check the filesystem:

for (i, _) in repo_branch.match_indices(separator.as_str()) {
    let candidate_path = parent_path.join(&repo_branch[..i]);
    if candidate_path.join(".git").exists() {
        return Some(RecoveredPath { repo_path: candidate_path });
    }
}

So it tries:

1. /home/user/git/my/.git — nope
2. /home/user/git/my.project/.git — exists, that's our repo

The separator characters are auto-detected from the template — whatever literal text sits between {{ repo }} and {{ branch }}. So {{ repo }}-{{ branch }} uses -, {{ repo }}_{{ branch }} uses _, and {{ repo }}--{{ branch }} uses --. Multi-character separators work because match_indices searches for the full substring.

Direct (e.g. .worktrees/ layout)

Templates like {{ repo_path }}/.worktrees/{{ branch | sanitize }} don't have the /../ collapse problem. repo_path appears directly in the path, so the regex captures it without ambiguity:

^(?P<repo_path>.+)/\.worktrees/(?P<branch>[^/]+)$

/home/user/code/myproject/.worktrees/feature-auth → repo_path = /home/user/code/myproject. No filesystem probing needed.

Tested situations

This approach worked well with:

• Simple repo + branch (orchestrator.feature-vt100)
• Repo names with dashes (my-cool-project.fix-bug-123)
• Repo names with dots (my.project.feature-x) — filesystem validation finds the right split
• Multiple dots (a.b.c.branch where only a.b.c/.git exists)
• .worktrees/ subdirectory layout
• Branches with slashes (feature/auth via raw {{ branch }})
• Non-dot separators (- and _)
• Ambiguous separators in repo names (my-project-feature-x with - separator — resolved by filesystem)
• Tilde expansion in templates
• No-match cases (no separator in path, primary worktree path, repo also deleted)

Limitations

• If the repo directory has also been deleted, there's no .git to validate against, so recovery fails. This seems acceptable — if the repo itself is gone, there's nothing to recover to.
• Templates without {{ repo_path }} in any form (e.g. a flat ~/worktrees/{{ repo }}.{{ branch }}) can't recover the repo path since there's no structural relationship to reverse.
• The left-to-right scan assumes the shortest repo name match is correct when multiple candidates have .git. In practice this is unlikely to be wrong, but a repo named a sitting next to a.b with both having .git would match a first.

[max-sixty]

this should be mostly handled now? let me know anything that doesn't quite work @davidbeesley , thank you again for the issues!

[davidbeesley]

No problem. Thanks for the fixes! I haven't seen any issues but I'll be sure to post something if it comes up.