Make Your Agents Take Turns Pushing Code

tl;dr — Claude Code Merge Queue is a free, local merge queue that forces your coding agents to take turns when they push — it still runs your full test suite with each commit and maintains a clean git history with no PRs and no Actions bill.

What a merge queue actually is

If you already know what a merge queue is, skip ahead. If you don’t, here’s the whole idea in one sentence: it’s a turnstile for your codebase. One change goes through at a time — the next one waits until the last one’s clear. Simple concept, real consequences once you actually need one.

One prerequisite before starting with merge queues: each agent needs its own isolated checkout, or they’ll clobber each other’s uncommitted files mid-edit. Just fire up your agent with one flag, native to Claude Code since v2.1.49 (Feb 2026):

claude --worktree <name>

That gives each agent their own lane to swim in, and claude-code-merge-queue can help them all land safely.

The problem

Run more than one coding agent on the same repo, and two of them will eventually finish at the same moment. Both try to push. One makes it, one gets rejected.

Here’s the expensive part: the rejected agent doesn’t just get a clean retry. It rebases and pushes again — and if a third agent finishes in that same window, its retry races too. The more agents you run, the more often this compounds instead of resolving itself. On top of that: four parallel builds melting your laptop, four dev servers you can’t tell apart, a shared test database getting reset mid-run by one of your other agents.

None of that is because the agents are bad at their jobs. Four fast, capable agents can each be excellent on their own — put them all in front of the same door with no one directing traffic, and everyone tries to walk through at once. That’s not a talent problem. It’s a coordination problem, and it needs a coordination fix.

The alternative you’ve probably already heard of

If any of this sounds familiar, you may already be thinking “isn’t this what a merge queue is for?” Good instinct — GitHub actually ships one, though it runs in their cloud, not your machine. It’s real, it works, and it’s worth understanding why it’s built for a different problem than yours.

It’s Enterprise-Cloud-only if your repo is private. Every attempt through it burns Actions minutes against your plan — and GitHub’s own pricing is trending toward more metering in 2026, not less. And it’s built entirely around pull requests: open one, get it reviewed, let the queue batch it in with everyone else’s.

If you’re one person running a team of agents, building on your own, you don’t want any of that. You don’t want to manage a stack of PRs. You don’t want a review gate for code only you’re going to read. You want your code in, tested, and done — without a bill for the privilege.

Skipping PRs isn’t skipping review — it’s swapping a human who doesn’t have time to read every diff for a machine that checks every single one.

What a local queue takes off your plate

No PRs. Every agent pushes, and the queue does the rest — one lands, the next waits its turn, automatically, no ticket to open and babysit.

Every landing runs the full check suite first — lint, typecheck, tests, build, end-to-end, whatever you’d trust in CI — for free, on your own machine. Nothing unverified ever reaches your main branch. It’s not a substitute for human review, but it doesn’t need to be: it’s a machine that runs the same checks every single time, without getting tired of it — which is more than most of us actually do reviewing our own solo commits.

History stays clean — one rebase per landing, no merge-commit sprawl to untangle six months later.

Pair it with the obvious next step — scope your real CI to only run on the branch you actually ship from — and the expensive part of CI happens exactly once: when you promote to production. That’s a few lines of CI config on your end, not something Claude Code Merge Queue does automatically, but it’s the natural pairing.

This is actually the part that changed how often I shipped: as I added more end-to-end tests, pushing straight to production got expensive, and not just on the successful runs — a push that fails CI on attempt one, then two, then three, burns real minutes every time, for a change that hasn’t even landed yet.

Verify it locally first, and by the time it reaches production, it’s already passed the exact same suite — you’re not paying to find out it’s broken.

What this doesn’t do

Worth saying straight: it’s one laptop, not a team — no reach across machines. It won’t stop an agent that’s deliberately trying to get around it — it’s built for mistakes, not sabotage. And there’s a real throughput ceiling: the queue holds for the length of your check suite, one landing at a time, which caps out under twenty landings an hour if your suite runs a few minutes.

Takeaways

You might not have this problem yet. One agent, one branch, nothing to collide with. But the second you add a second agent, or if you’re already managing a small swarm of them, you’ve probably felt this pain. Worth knowing what to reach for before you’re mid-collision trying to figure it out.

So check out Claude Code Merge Queue. Zero runtime dependencies, no Actions bill. Point your agent at it, and it wires itself in. Up and running in seconds.

Thanks for reading — hopefully this saves you the same collision I kept running into. If it helped, a star on the repo goes a long way, and I’d genuinely love to hear in the comments how you’re handling managing swarms of your own agents.