Git Worktrees vs a Hive: Two Ways to Parallelize Claude Code

There are two genuinely good answers to “how do I run Claude Code agents in parallel,” and they’re often pitched as rivals. They aren’t. Git worktrees and a coordinating hive solve different halves of the problem, and the right choice — or the right combination — depends on whether your parallel work is independent or interdependent. Here’s the honest comparison.

What git worktrees give you #

A worktree is an extra working directory attached to a single repository. Normally a repo has one checkout; git worktree add ../feature-x feature-x gives you a second directory with the feature-x branch checked out, sharing the same underlying repo.

git worktree add ../agent-a -b agent-a
git worktree add ../agent-b -b agent-b
# now agent A and agent B each have their own directory + branch

The key properties:

• Separate working directories. Each agent edits files in its own folder. They physically cannot step on each other’s uncommitted changes.
• Separate indexes. Each worktree has its own staging area, so an agent staging and committing in one doesn’t fight another’s index. (This sidesteps a lot of the index.lock pain you get when many processes share one index.)
• Shared history. They share the same object store and refs, so branches and commits are visible across all of them — no duplicate clones, no re-fetching.

For independent parallel work, this is often all you need. Three agents, three feature branches, three worktrees: they run side by side, each on its own task, and you merge the branches when they’re done. Clean and native.

Where worktrees stop #

Worktrees isolate workspaces. They do nothing about coordination. The moment your parallel agents aren’t fully independent, the gaps show:

• No shared memory. Agent A figures out a quirk in the build; agent B, in a different worktree, has no idea. Each is its own island. Nothing carries knowledge between them or across sessions.
• No messaging. If agent B needs something from agent A — a decision, an interface, a “don’t touch this module” — there’s no channel. You become the relay, copy-pasting between directories.
• No orchestration. Worktrees don’t divide a goal into tasks or assign them. You still decide, by hand, who works on what. There’s no coordinator reading “ship feature X with tests and docs” and routing the pieces.
• No shared plan or visibility. Three worktrees are three black boxes. There’s no shared board, no roster, no single place to see what the team is collectively doing.

In other words, worktrees make parallel agents safe to run, not able to cooperate. That’s a real and useful guarantee — it’s just not the same as a team.

What a hive gives you #

A hive is the coordination layer worktrees lack. It wraps several long-lived agents and adds:

• Shared, durable memory. Each agent’s notes persist and become recall-able by the whole team, so knowledge flows between agents and across sessions — semantic memory for agents, not isolated context.
• Direct messaging. Agents send messages to each other through a router; no human relay. (“I own the auth module” actually reaches everyone.)
• An orchestrator. A coordinator decomposes your goal, routes work to the right agent, adjudicates the routine back-and-forth, and escalates only the critical calls — see orchestrating Claude Code agents.
• A shared plan and a live view. One board, one roster, one office floor you can watch.

What a hive does not inherently solve is file isolation — if its agents share a single working directory, you need a discipline (single-writer files, single-committer git) to keep them from colliding. Which is exactly where worktrees come back in.

They compose #

Here’s the punchline the “vs.” framing hides: use both. Worktrees handle isolation; the hive handles coordination. Munder Difflin now ships this combination built-in: the Git isolation toggle in Add Agent provisions a dedicated worktree for each agent on spawn and tears it down on kill — so every agent in a shared repo works on its own branch by default, with no manual git worktree add needed.

            ┌─ worktree: agent-a (branch agent-a) ─┐
hive ───────┼─ worktree: agent-b (branch agent-b) ─┼── shared memory + messaging
(coordination) └─ worktree: agent-c (branch agent-c) ┘   + orchestrator + board

The layers don’t conflict; they stack. Worktrees are a git feature for workspace isolation. A hive is a coordination feature for teamwork. Asking which to use is like asking whether to use seatbelts or a steering wheel.

A decision guide #

Pick based on how interdependent your parallel work is:

Just worktrees are enough when:

• the tasks are independent (separate features, separate branches),
• agents don’t need to know what the others learned, and
• you’re happy to assign work and merge results by hand.

A hive (optionally over worktrees) is worth it when:

• the work is one goal that needs dividing and recombining,
• agents must share knowledge or message each other, or
• you want to state intent once and have a coordinated team execute — the leap described in how to run multiple Claude Code agents.

If you’ve ever wondered whether built-in mechanisms are enough versus an external coordination layer, the same question shows up for subagents vs a harness — and the answer rhymes: native primitives handle the small scale; a coordination layer handles the team scale. For a concrete tool-vs-tool take on that coordination layer, see Claude Squad vs Munder Difflin.

FAQ #

Do worktrees prevent all git conflicts? They prevent index and working-directory collisions, which are the common ones. Shared refs and the object store are still common, so concurrent operations that touch refs still want care — which is one reason a hive uses a single committer for its coordination repo even when agents work in separate worktrees.

Is a hive heavier than worktrees? It’s more capable, so it’s more machinery. If your tasks are truly independent, worktrees alone are the lighter, correct choice. Add the hive when coordination — not just isolation — is the thing you’re missing.

---

Munder Difflin is the coordination layer: shared memory, messaging, and a GOD orchestrator for a hive of Claude Code agents — and it plays nicely with the git workflow you already use. Download Munder Difflin when isolation isn’t enough and you need a team; it’s free and open source.

FAQ

What is a git worktree?

A git worktree is an additional working directory attached to one repository. Each worktree has its own checked-out branch and its own index, but they share the same object store and refs — so you can have several branches checked out at once without cloning the repo multiple times.

Are git worktrees enough to run parallel Claude Code agents?

For independent tasks on separate branches, often yes — worktrees give each agent its own files so they don't collide. What worktrees don't provide is coordination: shared memory, messaging between agents, or an orchestrator that divides one goal across the team.

Can I use worktrees and a hive together?

Yes. Worktrees solve workspace isolation; a hive solves coordination. You can run a coordinated hive where each agent works in its own worktree, getting both isolation and shared memory plus messaging. In Munder Difflin v0.1.6 this is built-in — the Git isolation toggle in Add Agent handles it automatically.

---