[orshih6]

The boot restore in WorkspaceView found worktrees only by listing <project>/.tempest. A branch opened directly into an existing worktree elsewhere on disk (the existingBranch.is_worktree path in the picker) was saved to SQLite with that outside path. That meant it was never added back to project.worktrees, and every session on it failed the prune check. pruneSessions then deleted those sessions from the DB, even though the folder still existed.

Changes:

• New pure helper src/components/worktreeRestore.ts:
  • externalBranchCandidates picks the saved branches of open projects that the .tempest scan didn't find.
  • anchoredSessionIds is the existing keep-or-prune decision, moved out of the component unchanged except that it takes the set of live worktree paths.
• On boot, each candidate's folder is checked with the existing list_directory command. Branches whose folder exists are added to the live set used by the prune and are appended to project.worktrees, so the sidebar row and its sessions come back. Branches whose folder is gone are still pruned, the same as before (no change to the [Bug]: Left sidebar resurrects stale/deleted sessions #129 behaviour).
• getAllBranches() added to the sessions store to expose the saved branch rows.

Testing:

• Added src/components/worktreeRestore.check.ts, which covers an external worktree that still exists (its session is kept), one whose folder is gone (pruned), an unknown branch id, and root sessions of open and closed projects. npm test worktreeRestore passes.
• npx tsc --noEmit reports no errors in the touched files. I installed only the root package, so the existing errors from the @tempest/* workspace packages that weren't built are unrelated.
• I haven't tested this in a running app. A reviewer may want to repeat the steps from the issue: run git worktree add ../wt/x x, open a session on x, then relaunch.

🤖 Generated with Claude Code

Fixes #151

---

This change was prepared with an AI coding agent (Claude) and reviewed by me before submitting. I'm happy to make any changes you'd like.

[vercel]

@orshih6 is attempting to deploy a commit to the Tempest OSS Team on Vercel.

A member of the Team first needs to authorize it.

[lvanhouten]

Thanks for picking this up so quickly! I reported #151, and this looks like the right fix: external worktrees whose folder still exists now survive the prune, come back in the sidebar, and get their sessions reopened. npx tsc --noEmit is clean and npm test passes on the branch for me (apart from the existing AgentQuotaStrip failure).

Three small things, none blocking:

1. Restored label differs from the live one. A branch opened directly into an existing worktree shows its branch name (/ → -) while the app is running, e.g. features-reuse-ladder-…. After a restart it comes back with the saved name, which is the folder basename (ensureBranch in sessions.ts), e.g. reuse-ladder-and-skip-consequence. That matches how .tempest rows restore, so it might be fine, but the label changes across a restart.
2. Existence check via list_directory. It reads the whole directory listing just to learn whether the folder exists, and any folder at that path counts, even one that's no longer a git worktree. A plain existence check (or confirming the path is still a worktree of the project) would say what it means.
3. A failed check still deletes sessions. If list_directory fails for a transient reason (an offline drive, a permissions error), the branch is treated as gone and its sessions are deleted from the DB, the same as before. Since the deletion is permanent, it might be safer to skip pruning when the check errors and only prune when the folder is confirmed missing.

Would you like to handle these, or would you prefer I open a follow-up PR?

[gsvprharsha]

Thanks @lvanhouten, all three are good flags.

1. Label drift across restart: noted, we will reconcile the saved name with the live display.
2. Switching to a proper existence (and worktree) check instead of list_directory.
3. Treating a failed check as keep rather than prune, so a transient I/O error cannot delete sessions.

We are working on these as follow-ups. Merging this into main now since it fixes the common case and the three items are additive on top.