[EN] Git Worktrees for Agentic Development: Running multiple coding agents in parallel

You are currently working on a feature. Claude Code is running in your terminal, in the middle of a major refactoring. Then you notice a critical bug in production that you need to fix immediately. What now?

If you work like most developers: git stash, switch branches, fix bugs, switch back, git stash pop, hope nothing collides. And while you do that, your agent stands still - after all, he can’t work in a repo that you’re pulling out from under him.

This is exactly where a problem becomes apparent that is hardly noticeable with classic software development, but is annoying every day with agentic development: a Git repository has exactly one checkout by default. One branch, one working directory, one state. As soon as you want to do several things at the same time - be it yourself plus an agent, or several agents working on different tasks in parallel - this one checkout becomes a bottleneck.

The solution to this has existed in Git since version 2.5, but is rarely used: Git Worktrees. They solve exactly the problem that parallel Agentic workflows would otherwise run into. In this article I’ll show you how they work and how you can actually use them to let multiple coding agents work at the same time - without them getting in each other’s way.

What are Git Worktrees?

A Git repository consists of two parts: the .git directory with the complete history, all branches and objects - and the working directory, i.e. the files that you actually see and edit. Usually these are linked one to one: a .git, a working directory, an active branch.

A worktree separates this connection. You get multiple working directories that all share the same .git directory. Think of the .git directory like a central library that several reading rooms use at the same time - each reading room has its own book open (its own branch, its own stand), but everyone accesses the same collection.

In practical terms, this means: You can have main checked out in one folder while feature/payment-refactor is running in a completely different folder at the same time - both belong to the same repository, share history and objects, but do not block each other. No stash, no back-and-forth checkout, no second git clone with double memory requirements for the complete history.

The command for this is git worktree. He manages exactly these additional working directories - how many, where they are, which branch is active there. What this looks like in detail will come in the practical part.

The problem (anti-pattern)

Imagine the following setup: You have Claude Code running in your project folder and have it working on a major refactoring. At the same time, you – or a second agent – want to quickly build a hotfix. The obvious thing would be: simply open a second terminal tab, in the same folder, change branch, and start working.

This goes wrong, and reliably:

Checkout conflict: git checkout or git switch switch the branch for the entire working directory. If you change the branch in the second terminal, it also changes for the agent in the first terminal - in the middle of his work. His open file changes suddenly end up on a different branch than he thinks.
Race conditions for file writes: Two processes write to the same files in the same directory. The agent reads a file while you save it in the editor - who wins is a coincidence.
Uncommitted Changes block you: If you want to change anyway, Git reports “Your local changes would be overwritten”. So stash. But alas, the agent is in the middle of a git add or commit - then you steal away his work without noticing.
Build artifacts clash with each other: node modules, compiler output, caches - everything relates to a file tree. Two build processes on the same tree can break each other.

The real crux of the problem: Agentic tools are designed to work autonomously across multiple files - often for minutes without you seeing every step. It is precisely this autonomy that makes them dangerous in the shared working directory. A person usually notices immediately when they are typing on the wrong branch. An agent only notices when his next diff no longer fits what he has in the context.

The solution (best practice)

Instead of multiple processes in a working directory, each agent - and you - gets their own. They all access the same .git directory, but work completely isolated from each other. Here’s how to set it up:

Create a new worktree for an existing branch:

# Im Hauptverzeichnis deines Repos
git worktree add ../mein-projekt-hotfix hotfix/payment-bug

This creates a new folder ../my-project-hotfix, checks out the branch hotfix/payment-bug there - and leaves your original checkout completely untouched.

A new worktree with a new branch in one step:

git worktree add -b feature/rate-limiting ../mein-projekt-rate-limiting

This simultaneously creates the feature/rate-limiting branch and the appropriate worktree for it. Practical if you want a fresh branch for each agent task.

Show all active worktrees:

git worktree list

/Users/julian/projekte/mein-projekt              abcd123 [main]
/Users/julian/projekte/mein-projekt-hotfix       ef01234 [hotfix/payment-bug]
/Users/julian/projekte/mein-projekt-rate-limiting 567890a [feature/rate-limiting]

Remove a worktree when the work is done:

git worktree remove ../mein-projekt-hotfix

Important: git worktree remove only deletes the folder if there are no uncommitted changes. If you still have open changes there, Git will refuse to remove them - a useful protection so that you don’t accidentally throw away agent work that has not yet been saved.

Cleanup when a folder is manually deleted:

If you have removed a Worktree folder manually in Finder or with rm -rf instead of via Git, a reference to it will still remain internally. Here’s how you clean it up:

git worktree prune

This means you have the tools at your fingertips. The actual benefit only becomes apparent in the actual Agentic workflow – more on that now.

Convenient workflow

Now it gets concrete: you have three things to do. A larger feature needs to move forward, a bug in production needs to go away, and you need a third topic for review. Instead of processing this sequentially, you divide the work into several worktrees - and run your own Claude code in each one.

Step 1: Create worktrees for each task

cd ~/projekte/mein-projekt

git worktree add -b feature/rate-limiting ../mein-projekt-rate-limiting
git worktree add -b hotfix/payment-bug ../mein-projekt-hotfix
git worktree add -b review/pr-142 ../mein-projekt-review origin/feature/pr-142

The third command checks out an existing remote branch - practical if you want to review a pull request locally without sacrificing your own checkout.

Step 2: Start your own agent in each worktree

# Terminal-Tab 1
cd ~/projekte/mein-projekt-rate-limiting
claude

# Terminal-Tab 2
cd ~/projekte/mein-projekt-hotfix
claude

# Terminal-Tab 3
cd ~/projekte/mein-projekt-review
claude

Each instance of Claude Code now works in its own directory, on its own branch, completely independent of the others. The agent in the hotfix worktree can commit while the agent in the feature worktree is in the middle of a refactoring - neither disturbs the other because neither sees the other’s files.

Step 3: Merge finished work

As soon as a task is finished, the merge runs as usual via the main checkout:

cd ~/projekte/mein-projekt
git checkout main
git merge hotfix/payment-bug
git push

Step 4: Clean up the worktree when it is no longer needed

git worktree remove ../mein-projekt-hotfix
git branch -d hotfix/payment-bug

The result: You can run as many parallel agent sessions as your machine can handle - each isolated, each on its own branch, without having to manually stash or context switch between tasks. The bottleneck from the introduction is now resolved.

Pro Tips/Warnings

Node modules & dependencies per worktree Each worktree has its own working directory - but no own node_modules, vendor folders or virtual environments. You have to install them separately in each worktree:
cd ../my-project-rate-limiting
npm install
Costs additional storage space and time during setup. For very large dependency trees, it is worth looking at package managers with global cache (e.g. pnpm), which share installed packages between worktrees instead of duplicating them.

.env files are not automatically copied .env files are typically located in .gitignore and therefore do not end up in a new worktree. You have to copy or link them manually:
cp ~/projects/my-project/.env ../my-project-rate-limiting/.env
If you forget this, your agent will start with a missing configuration - and in the worst case, it will only report a connection error to the database after a few minutes of work.

Keep an eye on storage space The .git directory is shared, but each working directory occupies its own space for source code, dependencies and build output. Three to four parallel worktrees with full node_modules quickly add up to several gigabytes. Clean up worktrees promptly as soon as a task is completed - not just when the hard drive is full.

Don’t forget the cleanup A worktree that you no longer need but do not remove will remain visible in git worktree list and will be confusing the next time you ask yourself which branch is where. Build a routine: After each merge, directly git worktree remove and git branch -d.

IDE configuration per worktree If you open each worktree as a separate project in your IDE, you will also get its own settings, run configurations and open tabs for each worktree - useful if you really want a clean separation between the tasks. The disadvantage: You have to set up settings such as code style or debugger configs that are not versioned once in each worktree.

Conclusion

Git worktrees solve a problem that is hardly noticeable with classic individual work, but costs time every day with agentic development: the one checkout that becomes a bottleneck as soon as more than one process wants to work on the repository at the same time. A .git directory, several independent working directories - each agent gets its own branch, its own files, without anyone getting in the way.

The switch will cost you a few minutes of setup: install dependencies per worktree, copy .env files, establish a cleanup routine. In return, you get true parallelism - multiple Claude Code instances working on different tasks at the same time, without you having to manually stash or switch between them.

The more responsibility you hand over to agents, the more important clean tooling around them becomes. Worktrees are a small but effective building block for this.