Git worktrees

A git worktree session runs against a dedicated worktree path instead of your default project tree. This allows multiple active task branches with cleaner isolation.

• Use one worktree session per larger feature or risky refactor.
• Keep review and validation isolated from unrelated local changes.
• Switch between task-specific worktrees without stashing your entire project repeatedly.

• Use a local session when you are doing a short, low-risk change and do not need branch-level isolation.
• Use a git worktree session when you need parallel task isolation, cleaner review boundaries, or multiple active branches at once.
• If you expect heavy context switching between tasks, worktrees usually reduce friction compared with repeatedly stashing/restoring one working tree.

• Parallel feature work without mixing unrelated diffs.
• Cleaner PR/review scope because each session stays in its own worktree path.
• Safer experimentation for risky refactors, since failures are easier to discard in isolation.
• Less stash churn when moving between separate tasks.

• Higher mental overhead: you must track which task/branch lives in which worktree.
• Git branch checkout constraints apply: a branch checked out in one worktree cannot be checked out in another worktree at the same time.
• More housekeeping is required (naming, cleanup, and occasional pruning of stale worktrees).
• Initial provisioning adds setup steps compared with staying in a single local session.

• The session execution target selector only appears for clean, idle sessions.
• Session kind switching to git worktree is guarded to empty sessions (before messages/todos accumulate).
• Provisioning runs through a pending -> ready workflow before the worktree is usable.

If worktree creation fails, the app reports the error and falls back to local session kind so you can continue without getting stuck in a broken state.