Two Claude Code sessions editing the same checkout will step on each other: one saves a file while the other is halfway through changing it, and both lose work. A git worktree gives each session its own working directory on its own branch, sharing one repository underneath, so the file conflicts disappear. This is Anthropic’s own documented way to run sessions in parallel (run parallel sessions with worktrees), and it pairs cleanly with Helmsman’s grid. For the wider set of habits worktrees slot into, see the Claude Code common workflows guide.
How do you set up a worktree per session?
Add a worktree as a sibling folder next to your repository, then spawn a session into it.
From inside your repo, create a worktree on a new branch:
git worktree add ../repo-feature -b feature-branchThat makes a fresh working copy at ../repo-feature, checked out on a new feature-branch. To base
one on a branch that already exists, drop the -b and name the branch instead:
git worktree add ../repo-fix bugfix-123As of July 2026 the claude CLI also has a built-in shortcut that does the create-and-enter step in
one command. Pass --worktree with a name and it creates an isolated worktree, by default under
.claude/worktrees/ on a new worktree-<name> branch, and starts Claude in it:
claude --worktree feature-authThe Helmsman pairing follows from this. Because a sibling worktree is just another folder under your
projects folder, it shows up in Helmsman like any project. Spawn one session into each worktree, and
every cell then works in its own checkout on its own branch, with no shared files to collide over.
The claude --worktree shortcut is the tidy one-step version when you are launching from a terminal;
sibling folders are what you point a Helmsman cell at.
What do worktrees isolate, and what do they not?
Worktrees isolate files. They do not isolate anything outside the repository: databases, ports, and running services are still shared.
Each tree has its own files and its own branch, so edits in one never reach another. They all share
one repository history and remote underneath, so a branch you push from a worktree lands in the same
repository as everything else. But everything past the filesystem is common ground. A session
running database migrations in one worktree rewrites the schema under a session reading that same
local database from another; two sessions that both claim the default dev-server port fight over it
however separate their checkouts are. The tradeoff in brief is on
Ways to run multiple Claude Code sessions; this section
is the practical handling. Give each tree its own port and database name through per-tree
environment settings (for worktrees the claude CLI creates, a .worktreeinclude file can copy
your gitignored .env files in), run services in a per-branch container so nothing overlaps, or
keep any task that starts a long-running service to one session while the others do stateless
edits.
How do you clean up?
Remove the worktree, prune the stale pointer, and delete the merged branch.
When a worktree has done its job, remove the folder:
git worktree remove ../repo-featureAdd --force if it still holds uncommitted changes you are sure about. If you deleted a worktree
folder by hand, clear the leftover bookkeeping entry:
git worktree pruneThen delete the branch once its work is merged:
git branch -d feature-branchKeep the set tidy. Leftover worktrees clutter your projects folder, and when Helmsman lists folders and you grep across them, stale trees make the spawns and the searches confusing.
For when a worktree is the right tool versus terminal tabs, tmux, or a dedicated app, see Ways to run multiple Claude Code sessions. Once each session has its own checkout, supervise parallel coding agents is the working method for keeping them all moving.