Claude Code Merge Queue

Anyone who's let several AI coding agents loose on the same repo knows the mess that follows: two agents try to land at once, builds collide, tests flake because they're fighting over the same shared resources. Claude Code Merge Queue, installable with a simple npm install --save-dev claude-code-merge-queue, exists to make that impossible rather than merely less likely. It serializes landings through a FIFO queue so pushes never race, and it locks builds machine-wide so redundant heavy compiles don't stack up.

The setup lives in one config file, and it's opinionated in a good way — branch prefixes, worktree suffixes, port assignments per lane, an integration branch, an optional separate production branch for teams that want a two-stage model. Get something wrong, like a negative port number or setting productionBranch equal to integrationBranch, and the tool fails immediately with every problem spelled out, instead of leaving you to debug a broken pipeline three steps later.

The comparison the project draws to GitHub's own Merge Queue is pointed. GitHub's version needs Enterprise Cloud, burns Actions minutes on every attempt, and requires a pull request. This one works on any plan, on any repo, costs nothing because it runs on your own hardware, and skips the PR entirely in favor of a direct rebase and push. A pre-push hook backs this up by rejecting any push straight to the integration branch, telling you the actual command to run instead — and if you haven't configured a checkCommand, every push fails by default rather than silently sneaking through unchecked.

The toolkit itself is compact: commands to hook into Claude's native worktree creation, lock builds, land changes, sync a main checkout, promote to production, preview a lane's live working tree without building anything, and prune worktrees once they've landed. Running init wires most of this up automatically — the config, a CLAUDE.md so the agent knows to land its own work once tests pass, the necessary git hooks, and a preflight script that gives you a real diagnosis instead of a bare 'command not found' when a branch goes stale.

But the project is refreshingly upfront about what it isn't. There's no human review step — a passing checkCommand is the only gate, and the tool can't tell a real test suite from an echo ok. It only coordinates one machine, not a fleet; two machines landing simultaneously just hit git's ordinary rejection. And it explicitly isn't a security boundary — an emergency environment variable can push past any protected branch with no second factor, because the whole system is built to stop mistakes, not a determined adversary with shell access. A slow check command also becomes a literal throughput ceiling, since the queue lock holds for its full duration; a three-to-four-minute suite caps you well under twenty landings an hour.