Claude Code Merge Queue Review 2026: Stop Parallel Agents Fighting Over Main

The moment you run a second Claude Code agent on the same repo, a new class of bug shows up — and it isn’t in your code. Two agents rebase at once. Two heavy builds fight over the same CPU. Two test runs grab the same port. Claude Code Merge Queue exists to make all of that impossible.

What is Claude Code Merge Queue?

It’s a local, zero-cost merge queue for parallel Claude Code agents. Several agents land, build, and test at the same time; the queue serializes those operations so push races, redundant heavy builds, and shared-resource test flakiness can’t happen.

Setup is two commands:

npm install --save-dev claude-code-merge-queue
npx claude-code-merge-queue init

init writes the config, a CLAUDE.md, the WorktreeCreate hook, and the land / sync / promote / preview scripts.

Key features

• FIFO landing queue — land rebases and pushes a lane onto the integration branch through a queue, so two lanes are never mid-push at once. Agents run it themselves.
• Machine-wide build lock — build-lock -- <cmd> serializes your build across every lane.
• Native Claude Code hook — the WorktreeCreate hook plugs numbered lanes (lane/1, lane/2, …) into Claude’s own worktree creation, each with its own port (portBase + n).
• A pre-push hook that makes land non-optional — a direct git push to the integration branch is rejected, with the correct command printed. The same hook runs your checkCommand before allowing a landing. No checkCommand configured means every push fails by default.
• Human-only promote — shipping the integration branch to production is explicitly never in an agent’s instructions and never automated.
• preview — instantly mirrors a lane’s live working tree, uncommitted changes included, onto your main checkout so you can look at it without a build.
• Loud config validation — a malformed config fails with every problem listed the moment any command loads it, not three steps later.

Who should use it?

If you run two or more Claude Code agents on one repository, this is close to essential infrastructure. If you run one agent, it’s pure overhead — there’s nothing to serialize.

It pairs naturally with wmux, which handles the orchestration side (panes, worktrees, fan-out) while the merge queue handles the landing side.

How it compares to GitHub’s Merge Queue

The project’s own comparison is fair and worth repeating:

	GitHub Merge Queue	Claude Code Merge Queue
Private repo	Enterprise Cloud only	Any plan, any repo
Cost per landing	Actions minutes, every attempt	$0 — runs on your machine
Requires	A pull request	Nothing — direct rebase + push

Same idea, run locally instead of in someone else’s billed cloud. The genuine limitation follows from that: because it runs on your machine, it serializes lanes on that machine. It is not a distributed team merge queue, and it doesn’t pretend to be.

Pros and cons

Pros: eliminates a real class of multi-agent bugs; zero runtime dependencies; free on any repo including private; safety defaults are strict (no check command means no landing); promote is deliberately human-only; loud config validation; MIT licensed with CI.

Cons: single-machine only, so not a substitute for a team merge queue; purpose-built around Claude Code’s worktree model rather than general-purpose CI; very young (created July 2026) with few forks and limited outside validation; you have to adopt its lane and branch conventions.

Pricing

Free and open source under MIT, published on npm with zero runtime dependencies. Requires Node 18+.

FAQ

Does it work with agents other than Claude Code? The WorktreeCreate hook is Claude Code specific, but land, build-lock, sync, and preview are ordinary CLI commands any agent or human can call.

What stops an agent pushing straight to main? A pre-push hook rejects it and prints the command to run instead. There’s an emergency hatch, but it requires naming the specific branch rather than passing a generic flag.

Do I need a pull request? No. It rebases and pushes directly, which is what makes it work on any plan and any repo.

Can it deploy to production? Only by a human. promote is documented as human-only and explicitly excluded from agent instructions.