Claude —worktree: When the AI Clones Type in Parallel
Recently I stumbled across this post by Boris Cherny on X , and my first instinct was: “Hold on… that can’t actually work, can it?”
The subject is the new claude --worktree flag in Claude Code. The promise: you can point multiple Claude instances at the same repo simultaneously to work on different features.
My brain immediately switched into Git-panic mode: “Two terminals in the same directory? What if I commit in both? That’s going to be the mother of all merge conflicts!”
I went down the rabbit hole — for you and for myself. Here’s why it doesn’t cause chaos and why it’s becoming my new favorite tool for day-to-day work.
The Problem with “Wait a Minute”
We all know it: you ask Claude to do a complex refactor or write a test suite. That might take 60 seconds. During that time you could already be working on the next CSS bug.
But you don’t dare touch the directory while the AI is reading and writing files. You’re blocked.
The Solution: Git Worktrees (The Magic Behind the Scenes)
Here’s the trick: Claude uses a Git feature I previously only knew by name — worktrees.
Imagine you have a book (your repo). Normally you can only have it open at one place at a time. A Git worktree is like placing a magical copy of the book in another room. Both copies share the same “storage” (the Git database), but you can write on page 10 in room A and on page 200 in room B — without grabbing the pen out of each other’s hands.
When you run claude --worktree, here’s what happens:
- Claude instantly creates a new branch in the background.
- It checks that branch out into a separate directory (tucked away under
.claude/worktrees/). - You’re not working in the same instance at all.
My New Workflow: Specialists and an Integrator
Once I understood that, the approach suddenly made sense. I now split the roles:
1. The Specialists (The “Workhorses”)
In Terminal 1 I say:
claude --worktree→ “Build the API integration for the weather widget.”
In Terminal 2 I say:
claude --worktree→ “Fix the responsive layout in the header.”
Both Claudes toil away in their own bubble. They don’t see each other, they don’t interfere. When they’re done, they commit their work to their own little feature branch.
2. The Integrator (The “Lead Developer”)
That’s me (with the help of the regular claude command) in my main directory. This is where the threads come together. I run git merge on both AI branches.
And yes, if both touched the same file, things will clash here. But that’s a good clash.
The “Aha” Moment with Merge Conflicts
That was my biggest concern: who sorts out the chaos?
The answer is simple: I ask the Claude in the main directory. Since it has an overview of the entire project, I just say:
“Hey Claude, I have a merge conflict between the weather widget and the header fix. Please look at the changes and combine them so both work.”
Since the AI understands the code context of both changes, it often resolves the conflict more intelligently than I could manually with <<<<<<< HEAD markers.
Conclusion: Welcome to the Parallel World
claude --worktree is a game changer for me. It removes the “serial” nature from programming. I no longer have to wait for the AI to finish before I can move on to the next thought.
Pro tip for Git hygiene: Don’t forget to occasionally run git worktree prune to clean up, so your hard drive doesn’t fill up with “spicy-napping-otter” or “clever-munching-toast” directories (yes, that’s genuinely how Claude names these worktrees).
How about you? Are you already using worktrees actively? Let me know as feedback — I just introduced this feature!
Addendum: —worktree in Practice
After some testing, I have to qualify my original post: For my actual work with Next.js/React, --worktree is not suitable.
The Problem
--worktree isolates not just spatially, but conceptually. What that means:
- .env files are visible in the directory listing but not available
- Only versioned files (git) are truly accessible
- Build tools like
bun run devor Next.js Devtools do not work node_modules, build cache, local configuration — all missing
You don’t notice it right away because the directory structure looks normal. But as soon as you try to run anything, you hit walls.
Where —worktree Actually Works Well
- Isolated code reviews
- Small, self-contained refactors
- Debugging individual components without environment dependencies
Not for:
- Running development environments
- Projects with build processes
- Anything that needs
.env,node_modules, or other local resources
My Recommendation
For Next.js/React projects: Skip --worktree.
Work directly in the project directory:
cd /path/to/your/project
claudeClaude has plenty of context through the file structure — and you have access to the complete environment.
TL;DR: --worktree sounds clever, but for productive development it’s often impractical. Sometimes the simple path is the better one.
This post originally appeared on martuni.de