Parallel worktrees

Run a project session in an isolated git worktree so changes land on their own branch; where it is created, how uncommitted changes come along, and how to merge when you are done.

A project session can run in its own parallel worktree (the session shows a "worktree" badge), with changes landing on a separate branch so nothing interferes with anything else.

The entry point is the "Run in" selector on the new session page: after picking a target project, that row reads "Run in Some Project · Local/Worktree · Branch", and switching the mode to "Worktree mode" opens an isolated worktree. Not every target can have one: only a plain folder inside a real git checkout that currently has a branch gets the worktree option and an optional branch. If the target is a multi-folder workspace, a project that has not been created yet, not a git checkout at all, or an empty repository with no commits, the "Worktree" item is greyed out with "Not available for this project", and the mode falls back to local. The reason is straightforward — in a multi-folder workspace each root is its own repository, so there is no such thing as a single current branch.

Merging is now an ordinary operation you do yourself on the git side; Klaus does not do it for you. The "Merge back to main checkout" button that used to be in the session menu, along with the merge channel behind it, has been removed entirely. That is deliberate — merging involves how conflicts get resolved, which branch to merge into, and whether to commit first, and those belong in your own git workflow rather than being decided for you by a button. The ⋯ menu of a worktree session now only offers "Show worktree in Finder".

The mechanism is plain git worktree:

On creation, a separate directory is checked out under ~/.klaus/worktrees/<repo-name>-<timestamp>, and a klaus/wt-<timestamp> branch is created (you can specify a base ref). The original repository must already have at least one commit, otherwise creation fails.
On creation, the main checkout's current uncommitted changes can come along — the "Run in" row has an "Include N uncommitted changes" switch (on by default): modifications and deletions of tracked files, plus untracked new files, are all copied over, while ignored files stay where they are. The main checkout itself is untouched; changes are copied, not moved. This switch only applies when the current HEAD is the base; if you explicitly pick another base ref, nothing is carried over, so two sets of state never get mixed.
The session's working directory points at that separate directory, so this session's changes land only on that branch.
Removing a worktree force-removes the directory (getting rid of the isolated directory is exactly the intent); the branch and its commits are kept. When deleting a worktree session you can also tick the option to remove the worktree directory along with it.
Only directories inside ~/.klaus/worktrees count as managed worktrees. That is a session-private workspace and is never treated as one of your projects.