Skip to main content
MindStudio
Pricing
Blog About
My Workspace
ClaudeWorkflowsProductivity

What Is Claude Code Git Worktree Support? How to Run Parallel Feature Branches

Claude Code now has native git worktree support, letting you work on multiple feature branches simultaneously without conflicts. Here's how to use it.

MindStudio Team
What Is Claude Code Git Worktree Support? How to Run Parallel Feature Branches

The Branch-Switching Problem Most Developers Hate

If you’ve ever been deep in a feature branch, only to get pulled into a critical bug fix, you know how painful context switching can be. Stash your work, check out a new branch, fix the bug, check out your feature branch again, pop the stash — and hope nothing breaks.

Claude Code’s native git worktree support changes this. Instead of switching between branches, you work on multiple branches at once in separate directories, with separate Claude Code instances running in parallel. The primary keyword here — Claude Code git worktree support — refers to the AI coding agent’s built-in awareness of git’s multi-directory checkout system, which allows parallel, conflict-free branch work.

This guide covers what git worktrees are, how Claude Code’s integration works, and how to set up a practical parallel workflow that actually saves time.


What Git Worktrees Are (and Why They Matter)

Git worktrees are a native git feature that lets you check out multiple branches simultaneously, each in its own directory on disk. They’ve been available since Git 2.5, but most developers haven’t made them part of their daily workflow because the tooling never made them easy enough to justify the setup.

Here’s the core concept: when you clone a repo, you get one working tree — one directory with one checked-out branch. With git worktree add, you can create additional working trees, each pointing to a different branch. All of them share the same git history, objects, and refs. None of them interfere with each other.

A few things this enables:

  • Simultaneous branch checkout: Feature A lives in /projects/app-feature-a, Feature B lives in /projects/app-feature-b, and both are checked out at the same time.
  • No stashing: You don’t lose your in-progress work when you need to switch contexts.
  • Independent build environments: Each worktree can have its own node_modules, .env files, or build artifacts without contaminating the others.
  • True parallelism: Tools (and AI agents) can run independently in each worktree without stepping on each other.

That last point is exactly where Claude Code comes in.


How Claude Code’s Native Worktree Support Works

Claude Code is Anthropic’s terminal-based AI coding agent. It reads and writes code, runs shell commands, runs tests, and operates largely autonomously within a project directory. By default, it’s scoped to whatever directory you launch it in.

When you launch Claude Code inside a git worktree, it recognizes the worktree context. It knows which branch it’s on, which worktrees exist in the project, and how the current directory relates to the main repository. This awareness prevents it from making changes that would corrupt shared git state or conflict with other active worktrees.

More importantly, you can run separate Claude Code instances in separate worktrees at the same time. Each instance operates independently:

  • Its own branch
  • Its own working directory
  • Its own context window and conversation
  • Its own test runs and terminal commands

This means if you’re building a new payments feature in one worktree, Claude Code is writing and testing that code. Meanwhile, in a second worktree on a hotfix branch, another Claude Code instance is diagnosing and patching the bug — completely in parallel, no interference.

The practical throughput gain here is significant. Work that would otherwise be sequential becomes concurrent.


How to Set Up Git Worktrees for Claude Code

Prerequisites

Before you start, make sure you have:

  • Git 2.5 or later — Run git --version to check. Most modern systems are well past this.
  • Claude Code installed — Follow Anthropic’s setup instructions if you haven’t already.
  • A git repository — Either an existing project or a fresh one.

Step 1: Create Your Main Repository (or Use an Existing One)

Your main repository directory is automatically your primary worktree. Nothing special to do here.

cd /projects/my-app
git status  # Confirm you're in a repo
git worktree list  # Shows the main worktree

The git worktree list command will show something like:

/projects/my-app  abc1234 [main]

Step 2: Add a New Worktree for a Feature Branch

Create a worktree for your first feature. The convention is to put worktrees as sibling directories to your main repo:

# Create a new branch and worktree at the same time
git worktree add ../my-app-feature-payments feature/payments

# Or check out an existing branch in a new worktree
git worktree add ../my-app-hotfix-auth hotfix/auth-validation

After running these, your directory structure looks like:

/projects/
  my-app/              # Main worktree (main branch)
  my-app-feature-payments/   # Linked worktree (feature/payments)
  my-app-hotfix-auth/        # Linked worktree (hotfix/auth-validation)

Run git worktree list again to confirm all three are registered.

Step 3: Open Claude Code in Each Worktree

Open separate terminal windows (or panes in tmux/iTerm) for each worktree. In each one, navigate to the worktree directory and start Claude Code:

Terminal 1 — Feature branch:

cd /projects/my-app-feature-payments
claude  # or however you invoke Claude Code

Terminal 2 — Hotfix branch:

cd /projects/my-app-hotfix-auth
claude

Each Claude Code instance now operates in its own branch context. Give each one its own task, and they run in parallel.

Step 4: Clean Up Worktrees When Done

When a branch is merged and you’re done with it, remove the worktree:

git worktree remove ../my-app-hotfix-auth

If there are uncommitted changes, you’ll need to add --force. Once removed, the directory is deleted and the worktree registration is cleared from git.


Practical Parallel Workflows

Parallel Feature Development

The most common use case is working on two unrelated features at the same time. Create a worktree for each, launch a Claude Code instance in each, and give them separate instructions.

One instance might be writing API endpoints for a new user onboarding flow. The other is building the email notification system. Neither branch touches the same files, so there’s no merge conflict risk during development.

When both are ready, you merge them into main separately, just as you would normally.

Hotfix While Feature Work Continues

You’re three hours into a complex refactor on a feature branch. A production bug comes in that needs fixing immediately.

Without worktrees, you’d stash your changes, check out main, create a hotfix branch, fix it, push it, then switch back and pop your stash — hoping nothing breaks in the process.

With worktrees:

  1. Run git worktree add ../app-hotfix hotfix/critical-bug from any terminal.
  2. Open Claude Code in that new directory.
  3. Fix the bug, push the branch, open a PR.
  4. Your feature work is untouched and still running in its worktree.

The whole context switch takes 30 seconds instead of 10 minutes.

Parallel Experimentation

Sometimes you want to try two different approaches to the same problem. Refactoring a data layer with approach A in one worktree and approach B in another lets you run both to completion before deciding which to keep.

Claude Code is particularly good at this kind of parallel exploration because you can give each instance a different constraint or direction. One might optimize for readability, another for performance. Compare the results, pick the better one, delete the other worktree.

Code Review Preparation

If you’re reviewing a colleague’s PR, you can check out their branch in a worktree without abandoning your current work:

git worktree add ../app-pr-review-123 origin/feature/colleague-branch

Open Claude Code there and ask it to summarize the changes, run tests, or identify potential issues. Your own work stays exactly where it was.


Best Practices and Common Mistakes

Do: Use a Consistent Naming Convention

Name your worktree directories so they’re easy to identify at a glance. Prefixing with the main repo name helps:

my-app-feature-payments
my-app-hotfix-auth
my-app-experiment-new-db

This prevents confusion when you have several active worktrees.

Do: Keep Worktrees Short-Lived

Worktrees work best when they’re temporary. Create one for a specific task, finish that task, remove the worktree. If a worktree lives for weeks, it starts to accumulate drift — different dependency versions, config differences, etc.

Don’t: Check Out the Same Branch in Multiple Worktrees

Git won’t let you do this for good reason. Each worktree must be on a unique branch. If you try to add a worktree for a branch that’s already checked out somewhere, git will error out.

# This will fail if 'feature/payments' is already checked out
git worktree add ../another-payments feature/payments
# Error: fatal: 'feature/payments' is already checked out at '...'

Don’t: Share .env Files Carelessly

Each worktree is its own working directory, but they share the git repo. A .env file in your main worktree doesn’t exist in a linked worktree unless you copy it. This is usually a good thing — you might want different environment variables per branch — but it catches people off guard.

Set up .env files in each worktree independently, or use a tool like direnv to manage this automatically.

Do: Tell Claude Code Explicitly What You Want Done

Since each Claude Code instance is running independently with no shared context, be explicit about the task in each one. Don’t assume one instance knows what the other is doing. Treat each Claude Code session as a fresh conversation scoped to that branch.

Watch Out for Shared Resources

If multiple worktrees are running tests that hit the same local database or port, you’ll get conflicts that have nothing to do with git. Use different ports or database names per worktree, or make sure your test setup handles isolation.


Where MindStudio Fits in an AI-Assisted Dev Workflow

Claude Code in parallel worktrees is a great way to accelerate the coding process. But once you’ve built something — especially if what you’re building involves AI features, automations, or integrations — you still need somewhere to host and run those capabilities.

This is where MindStudio becomes relevant. If you’re using Claude Code to develop AI-powered features (agent workflows, automated data pipelines, AI-enhanced user experiences), MindStudio gives you a place to build, test, and deploy those without writing infrastructure code from scratch.

The most direct connection for developers using Claude Code: the MindStudio Agent Skills Plugin. It’s an npm SDK (@mindstudio-ai/agent) that lets Claude Code and other AI agents call over 120 typed capabilities — agent.sendEmail(), agent.searchGoogle(), agent.generateImage(), agent.runWorkflow() — as simple method calls. MindStudio handles the rate limiting, retries, and auth. Your agent focuses on the logic.

If you’re running parallel Claude Code instances across multiple worktrees, each one could be calling MindStudio Skills independently — one building an email notification pipeline, another building a document processing workflow — each in its own branch, each deployable on its own timeline.

Beyond the SDK, MindStudio’s visual agent builder supports 200+ AI models and 1,000+ integrations with no API keys required. It takes most teams 15 minutes to an hour to build a working agent. So while Claude Code handles your codebase, MindStudio handles the surrounding AI infrastructure.

You can try MindStudio free at mindstudio.ai.


Frequently Asked Questions

What is a git worktree and how is it different from a branch?

A branch is a pointer to a commit in git history. A worktree is a physical directory on disk with a branch checked out in it. You can have one branch but multiple worktrees isn’t possible for the same branch — but you can have multiple worktrees each pointing to different branches. Think of branches as bookmarks in your history and worktrees as the actual reading copies of a book.

Can I run multiple Claude Code instances in the same repository?

Yes, that’s exactly the point of the worktree workflow. Each Claude Code instance needs to be launched in a separate directory (a separate worktree), not in the same directory. Launching two instances in the same directory would cause conflicts. With worktrees, each instance gets its own directory and branch, so they operate independently.

Does Claude Code automatically detect when it’s inside a git worktree?

Yes. Claude Code reads the git context of whatever directory it’s launched in. If you start it inside a linked worktree, it knows which branch it’s on, what the main worktree is, and how the repository is structured. This is what makes the parallel workflow safe — Claude Code won’t accidentally make changes that corrupt shared git state.

How many worktrees can I have at once?

There’s no hard limit imposed by git. In practice, the limit is your machine’s resources — disk space, memory (if you’re running node_modules or build artifacts per worktree), and your ability to manage multiple active contexts. Most developers find 2–4 active worktrees at a time is a practical ceiling before things get hard to track.

What happens to my worktrees if I delete a branch?

Git will warn you if you try to delete a branch that has a worktree checked out. You typically need to remove the worktree first with git worktree remove, then delete the branch. If the branch is already merged and you force-delete it, the worktree directory remains on disk but becomes detached — it’s safer to remove the worktree before branch deletion.

Is the git worktree workflow compatible with monorepos?

Yes, and monorepos often benefit most from it. In a monorepo, you might be working on a change to Package A and a separate change to Package B at the same time. With worktrees, each change gets its own directory and its own Claude Code instance, which is especially useful because Package A and Package B might have completely different build and test commands.


Key Takeaways

  • Git worktrees let you check out multiple branches simultaneously, each in its own directory, with no stashing or context switching required.
  • Claude Code’s native worktree support means it understands the worktree context and won’t corrupt shared git state — making it safe to run parallel instances.
  • The setup is simple: git worktree add ../sibling-dir branch-name, then launch Claude Code in each directory.
  • Practical use cases include parallel feature development, hotfixes during active feature work, experimentation with multiple approaches, and isolated code review.
  • Common pitfalls include sharing the same branch across worktrees (git blocks this), forgetting to set up .env files per worktree, and resource conflicts like shared ports during testing.
  • MindStudio complements this workflow for teams building AI-powered features — its Agent Skills Plugin lets Claude Code and other agents call external capabilities as simple method calls, and its visual builder handles the broader AI infrastructure.

If you’re using Claude Code regularly, adding worktrees to your workflow is one of the higher-leverage changes you can make. The setup takes a few minutes, and the productivity gain on any multi-threaded development task is immediate.

Presented by MindStudio

No spam. Unsubscribe anytime.