Claude Code Git Worktrees for Client Work: Run Two Builds at Once Without Breaking Main
- A git worktree is a second working folder attached to the same repository, checked out on its own branch. Open each folder in its own Claude Code session and you have two agents working the same client project in parallel with zero risk of them editing the same files at the same time.
- The highest-value client use is the hotfix lane: when a client reports a live bug mid-feature, you do not stash half-finished work or wait for the feature to land. You open the second worktree, fix and ship from a clean branch, and the feature session never notices.
- Keep it to two lanes on a paid build - a feature lane and a hotfix lane. More lanes than that on one repo is how you end up merging against yourself, and the merge is where parallel work goes to die.
What a Git Worktree Does in Claude Code
A git worktree is a second working copy of a repository that lives in its own folder and sits on its own branch, while sharing the same underlying git history as the original. You create one with a single command - git worktree add ../client-hotfix fix/urgent - and you now have two folders on disk, each a fully functional checkout, each on a different branch, both pointing at the same repo.
For Claude Code this matters because the desktop app works one project folder at a time. One session, one folder, one branch. Open the main checkout in one session and the worktree folder in a second session, and you have two agents building against the same client codebase in parallel - and because each session lives in its own folder on its own branch, neither can overwrite the other's in-progress files. That physical separation is the whole trick. It is what a stash, a second tab, or careful branch switching inside one folder cannot give you.
When a Worktree Beats a Second Clone or a Stash
The short answer: use a worktree whenever you need two branches of one client repo active at the same time. The classic trigger on paid work is the mid-build interruption - you are three days into a feature branch and the client messages that something is broken in production. Without a worktree you either stash half-finished work and switch branches in place, which is exactly how half-finished work leaks into a hotfix, or you clone the repo again and wait through a second install. The worktree is the clean third option.
| Approach | What it costs you | When it is the right call |
|---|---|---|
| Stash and switch branches in place | One folder, one session; easy to carry half-finished edits into the fix | A one-line change you will make and ship in minutes |
| Clone the repo a second time | A full second copy, a second install, and two histories to keep in sync | Truly separate long-lived copies, like a client fork |
| Add a worktree | One extra folder, same repo, own branch; a second dependency install for most stacks | A live fix or review that must not touch the feature in flight |
Handling a mid-build interruption on a client repo
One honest caveat: a worktree shares git history, not build artifacts. For most stacks the new folder still needs its own dependency install before anything runs, so the second lane is not free - it is just far cheaper and far safer than the alternatives. If your real problem is many clients rather than many branches of one client, that is a different discipline - see [running multiple Claude Code client projects at once](/blog/run-multiple-claude-code-client-projects-at-once).
The Two-Lane Setup for a Paid Build
This is the Profit Room's Two-Lane Setup: one repo, two folders, two Claude Code sessions, each lane with one job. The feature lane is the main checkout on the feature branch, where the long-running build lives. The hotfix lane is a worktree folder you keep ready, cut from the main branch, reserved for live fixes, client-reported bugs, and quick review requests.
- From the client repo, add the lane: git worktree add ../clientname-hotfix -b fix/issue main. Keep the folder name obvious - you want to know which lane you are in at a glance.
- Open the new folder in its own Claude Code session and run the project's install command so the lane actually builds and tests.
- Do the fix in the hotfix lane only. Verify it with the project's own test and build commands before it goes anywhere near the client.
- Merge or push the fix branch, tell the client it is live, then pull main back into your feature branch in the feature lane so the two lanes do not drift.
- When the fix has shipped, remove the lane with git worktree remove so dead folders do not pile up - or keep one standing hotfix worktree per active client if interruptions are routine.
The same two-lane shape works for review: while the feature session keeps building, open the second lane on the branch under review and let a fresh session read it cold, the way [a subagent workflow splits building from checking](/blog/claude-code-subagent-workflow-for-client-work). A session that did not write the code critiques it better than the one that did.
Guardrails That Keep Parallel Lanes Safe on Client Work
Parallel lanes fail at the merge, so the guardrails are all about keeping the lanes from colliding. Give each lane one job and keep the jobs in different parts of the codebase whenever you can. Two sessions editing the same file on two branches merge into a headache you resolve by hand, on the clock, on a paid build. And cap it at two lanes per client repo - a feature lane and a hotfix lane cover the real cases, and a third lane usually means you are merging against yourself by Friday.
Worked cleanly, the two-lane setup changes how you show up to clients: the live bug gets fixed the same day and the feature still lands on schedule, which is exactly the story you want to tell in [the weekly client update](/blog/weekly-client-update-prevents-fires). Interruptions stop costing you the afternoon, and that reliability is what clients renew for.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What is a git worktree in plain terms?
A git worktree is a second working folder attached to the same repository, checked out on its own branch. You create one with git worktree add, and you end up with two folders on disk that share one git history. Each folder can be opened in its own Claude Code session, so two sessions can work the same client project on different branches at the same time without touching each other's files.
Why use a worktree instead of just switching branches?
Switching branches in one folder means one session and one working state - anything half-finished has to be stashed or committed before you can switch, and it is easy to carry stray edits into a branch where they do not belong. A worktree gives the second branch its own folder, so the half-finished feature stays exactly as you left it while you fix the urgent thing in a physically separate lane. For a quick one-line change, switching in place is still fine.
Can two Claude Code sessions run on the same repository at once?
Yes, and worktrees are the clean way to do it. Each session opens its own folder, each folder sits on its own branch, and the shared git history keeps everything in one repo. The sessions cannot edit each other's working files because they are in different directories. The place the two lines of work meet is the merge, which is why each lane should have one job and the jobs should live in different parts of the codebase where possible.
Do worktrees share installed dependencies?
No. A worktree shares the repository's git history and tracked files, but build artifacts and installed dependencies like a node_modules folder are not tracked, so a new worktree needs its own install before the project runs. Budget a few minutes for that when you cut a new lane, or keep a standing hotfix worktree per active client so the lane is always warm when an urgent request lands.
How many worktrees should I run on one client project?
Two lanes covers real client work: a feature lane where the long-running build lives, and a hotfix lane for live bugs, urgent requests, and cold-eyed review. Beyond two, the odds rise fast that lanes overlap in the same files and you spend billable time merging your own parallel work. If the pressure is many clients rather than many branches, the answer is separate repos and separate sessions per client, not more worktrees on one repo.
Last reviewed September 17, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
