Isolation Modes
GSD supports three isolation modes, set viagit.isolation in your PREFERENCES.md:
none
Default. Work happens directly on your current branch. No worktree or milestone branch is created. Best for hot-reload workflows or small projects where branch overhead isn’t worth it.
worktree
Each milestone gets its own directory at
.gsd-worktrees/<MID>/ (a sibling of .gsd/ at your project root) on a milestone/<MID> branch. Work is fully isolated. Squash-merged to main on completion.branch
Work stays in the project root but on a
milestone/<MID> branch. No separate directory. Useful for submodule-heavy repos where worktrees cause symlink problems.PREFERENCES.md:
Worktree mode requires at least one commit in the repository. In a zero-commit repo, GSD temporarily falls back to
none mode until the first commit exists, then automatically resolves to worktree.Worktree Location
Newly created worktrees live at<projectRoot>/.gsd-worktrees/<MID>/ — a sibling of the .gsd/ state directory, kept at the project root regardless of where .gsd state is stored. This keeps every worktree visible next to your project and out of any external state location.
Legacy location still works. Worktrees created under the older
.gsd/worktrees/<MID>/ layout remain fully recognized for resolution, listing, merge, and teardown — no migration step is required. Only newly created worktrees use the canonical .gsd-worktrees/ location, so in-flight milestones survive the upgrade unchanged..gsd/ ignored in your repo, add the canonical location to .gitignore as well (GSD does this automatically when git.manage_gitignore: true):
Worktree CLI Commands
Use these commands from your shell (outside a GSD session) to inspect and manage worktrees:In-Session Worktree Commands
From inside an active GSD TUI session, use the/gsd worktree family of commands (alias: /gsd wt):
Starting a Session in a Specific Worktree
Use the--worktree flag (short: -w) when launching GSD to open a session directly inside a named worktree:
Merge Behavior
When a worktree milestone completes, GSD handles the merge automatically:1
Sequential commits on the milestone branch
All task commits land on
milestone/<MID> with conventional commit messages and GSD-Task trailers.2
Squash merge to main
By default, all commits are squashed into one clean commit on your main branch. Change this with
git.merge_strategy: merge to preserve individual commits.3
Worktree and branch cleanup
The worktree directory and milestone branch are removed automatically after a successful merge.
Milestone Completion in Interactive Sessions
When you complete a milestone interactively — by runninggsd_complete_milestone from inside a chat or TUI session — GSD now closes out the milestone’s Git state for you instead of leaving the working tree untouched.
On every interactive milestone completion, GSD:
- Auto-commits the dirty working tree on the current branch with a conventional commit message and a
GSD-Unit: <milestoneId>trailer, so the commit is recognizable as milestone closeout evidence. A clean tree is left alone. - Computes a Closeout Git Verdict when
git.isolationisworktreeorbranch, and surfaces one of two notices when the situation needs your attention:
Needs attention — isolation bypassed
The milestone was completed outside a
milestone/<MID> worktree or branch even though git.isolation is worktree or branch. GSD commits the work where it sits and emits a warning naming the isolation preference that was not honored this session, so the milestone never closes silently on the wrong branch.Merge deferred to worktree tooling
The milestone was completed on its
milestone/<MID> branch as expected. GSD commits the work and emits an info notice pointing you at /gsd worktree merge to land the branch on your integration branch.Interactive closeout only fires on milestone boundaries.
gsd_task_complete and gsd_slice_complete deliberately do not auto-commit — committing at every task or slice would sweep up unrelated working-tree changes. Auto-mode is also untouched: it keeps its existing closeout pipeline.Parallel Milestones
When you have independent milestones, you can run them simultaneously in separate worktrees. GSD’s parallel orchestration engine manages worker processes, coordinates shared project state, and merges back to main when each milestone finishes. Use the/gsd parallel commands to manage parallel execution:
Enable parallel mode in your preferences before using these commands:
Safety Behavior
Auto-commit before merge
worktree merge auto-commits dirty files in the worktree before merging when possible, so you don’t lose uncommitted work.Conflict-aware merge
Merge stops and reports which files conflict rather than silently failing. Resolve manually, then retry with
/gsd parallel merge <MID>.Clean only safe worktrees
worktree clean never removes worktrees with pending diffs or uncommitted changes — only merged or empty ones.Detached HEAD protection
Merge and worktree flows refuse to proceed from a detached project root. Check out your integration branch first.
Worktree Post-Create Hooks
Run a custom script automatically after GSD creates a new worktree — useful for copying.env files, symlinking asset directories, or running setup commands the worktree doesn’t inherit from the main tree:
SOURCE_DIR (the original project root) and WORKTREE_DIR (the newly created worktree path).
