On my team everyone runs a coding agent, mostly Claude Code and some Codex. Each one works fine alone. Put four of them in the same repository at the same time and you get a bug I hadn't seen before.

Ana asks her agent to rename priceWithTax to grossPrice, and it renames every caller it can find. At the same moment Bea asks her agent for a new POST /invoices endpoint. Her agent reads the billing module, sees priceWithTax, and writes a new file that calls it.

The two agents never touched the same file, so git merges both without complaint, and the build is broken until someone runs it. Neither agent had any way to know the other existed. That's the problem I started building Lanes for.

What Lanes does

Lanes is a small server plus a hook for each agent.

File leases with a queue

Before an agent edits a file, it takes a lease. If a second agent wants the same file, it waits in a short queue, gets the newer version, and then makes its edit.

Lanes never refuses an edit. I tried refusing them early on, and 4 of 13 agents whose edit was refused (31%) stopped and asked their human what to do, which is the opposite of what you want from an agent. With a queue instead, 1 of 216 sessions asked. If the Lanes server is down or the wait runs out, the edit goes ahead uncoordinated, because I'd rather lose coordination than leave an agent stuck.

Shared team context

Leases can't catch the rename above, since the two agents work in different files. Team context can. It's off until you turn it on for a repository.

With it on, each prompt gets a short brief of who is working on what. When an agent reads or edits a file a teammate is changing, it gets a one-line heads-up. And at the end of a turn, if a file its code depends on changed underneath it, the agent is asked once to re-check before it stops.

Requests between agents

You can ask a teammate's agent to do something, say "add the migration for the column I just added". It only reaches their agent after they approve it. I left the approve tool out of the MCP server on purpose, so an agent can't approve its own request.

You can watch all of this from the CLI, the MCP server, or a browser app that your Lanes server serves. There's a VS Code extension too, but you don't need it.

The Lanes browser app: a lane per file showing who holds it and who is queued

What the benchmark shows

I wrote the benchmark method down before running anything, and every run is published, including the ones that make Lanes look bad.

The plumbing holds up. The hook check before an edit adds 39 ms at p95 on Linux and 68 ms on Windows. With 64 agents writing at once on one server, no edit was lost, and all 107 commits in the attribution test went to the right person.

The team-context result is smaller than I'd like. In the rename and signature-change scenarios, team context passed 20 of 20 runs and leases alone passed 17 of 20 (Claude Haiku, 10 runs each). That fits the idea that team context fixes the problem, but the control didn't fail often enough to prove it.

So I ran a timing sweep that starts the second agent 0, 4, 16 or 30 seconds after the first, to make the control fail more often. At 4 seconds it caught Lanes missing a case. Bea's agent pulled in Ana's rename just before its first write, after it had already decided what to write. Nothing recorded that the rename had arrived, so the end-of-turn check never fired, and Ana's agent had already finished, so nobody fixed the caller.

I've fixed that and added a test that fails without the fix. I'm rerunning the sweep, and the results go in the repo whichever way they come out. The method and every run are in the repo.

Try it

You need Node.js 22.18+ and git.

git clone https://github.com/mfmatozza/lanes cd lanes && npm ci && npm run build alias lanes="node $PWD/dist/lanes.cjs" cd your-repo lanes init --agents claude,codex lanes team on lanes doctor 

I've only tested Claude Code live. Codex, Gemini CLI, Cursor, Copilot and the rest are wired up from their hook docs and haven't been run against the real agents yet, so if you try one of those I'd like to hear what breaks. Lanes is Apache-2.0.

Coming up in this series

Part 2 is about the benchmark: how to measure agents stepping on each other without fooling yourself, and the bug the timing sweep found. Part 3 is about why Lanes never refuses an edit, and what agents do when you block them.

If your team already runs several agents in one repo, what goes wrong for you that this doesn't cover? I'd like to hear it in the comments.