Lanes.
GitHubGet started

Every agent gets its own lane.

Run as many coding agents as you want on one repo, without them getting in each other's way.

Star on GitHub
brew install lane

Pre-release: install commands go live with the first release.

  1. 01fix-authboth lanes editing validateSession()lane promote fix-authClaude Code
  2. 02add-testsCodex
  3. 03new-billingCursor
  4. 04refactor-dbGemini CLI

fix-auth and add-tests just reached the same function. Lanes flags it now, while both agents are still working, instead of at merge time.

Many agents. No pile-ups.

Running several agents on one repo usually means copies, installs and clashes. A lane removes each one.

  • Without Lanes: A full copy of your repo for every agentWith Lanes: An instant lane that uses almost no extra disk space
  • Without Lanes: A fresh npm install (or cargo build, or pip install) for every copyWith Lanes: Dependencies ready in every lane, from the start
  • Without Lanes: Five dev servers fighting over port 3000With Lanes: Its own ports and URL, like fix-auth.localhost
  • Without Lanes: Agents breaking each other's database with their migrationsWith Lanes: Its own database copy (Postgres, SQLite) and Docker Compose project
  • Without Lanes: Finding out two agents edited the same function only when you mergeWith Lanes: A warning while they are still working

  1. Undo anything

    A checkpoint after every agent step. lane undo takes back any step; lane restore jumps back to any checkpoint.

  2. Best of N

    lane race gives one task to several agents, runs the tests in each and shows a scoreboard. You keep the best one.

  3. Kind to your laptop

    Builds and tests take turns, so five agents don't freeze your machine. Dev servers start only when you open them.

  4. Stays on your machine

    Works offline. The only thing Lanes sends is an anonymous install count, and lane telemetry off stops it.

Curved lanes of a running track, seen from above, in black and white

Photo: H&CO, Unsplash

One repo in. One clean PR out.

  1. Your repo

    Keep your Git repo, your GitHub and your agents as they are. Nothing to migrate.

  2. A lane per agent

    Each agent gets an instant, ready-to-run lane with its own URL, ports and database. Any Git worktree an agent makes becomes a lane on its own.

  3. A warning, not a merge conflict

    The moment two agents open the same function, you see it on both lanes. They can keep going, or you can step in.

  4. One clean PR

    Keep the best lane and turn it into one pull request, with who (and which agent) wrote what. The rest stay out of your branch.

How Lanes worksYour repo splits into three lanes, fix-auth, add-tests and new-billing, each with its own URL, port and database. Lanes warns when fix-auth and add-tests edit the same function, and fix-auth merges back as one clean pull request.your-repo.gitnode_modules/.envfix-authClaude Codefix-auth.localhost:3001db fix_authadd-testsCodexadd-tests.localhost:3002db add_testsnew-billingCursornew-billing.localhost:3003db new_billingboth editing validateSession()PROne clean PR
lane promote fix-auth

Built-in guardrails.

Agents can't stop to ask. So Lanes checks every edit against the latest version, holds protected files for a person, and records which agent made each change.

  1. Edits that can’t clobber

    Every patch an agent sends names the version of the file it was made against. If another lane or tool changed it since, the patch is refused with the current lines, and the agent tries again. Nothing is overwritten silently.

  2. A person approves what matters

    Agents can’t stop and ask, so Lanes asks for them. A promote that touches protected files, like migrations or CI config, waits for a short code you approve in the terminal app.

  3. Every agent has a name

    Each lane records which agent works in it, with its model and session, all the way into the pull request. With Autter, an agent can also get its own access, limited to the repos you pick, that you can switch off at once.

  4. Start from any branch

    Make a lane from any branch or ref with lane new --from. When another tool makes its own worktree for a task, Lanes turns it into a lane too.

Terminal~/your-repo
  1. agentlane promote fix-auth
  2. protected: migrations/0042_sessions.sql
  3. needs approval · code 7KQ-2MD · expires in 10:00
  4. youlane approve 7KQ-2MD
  5. approved by you · recorded in the PR
  6. fix-auth promoted · pull request opened
Example session. The code expires after 10 minutes and works once.

Runs where your agents run.

On your laptop, in the sandboxes cloud agents use, and on the code host you already have. Nothing to migrate.

macOS, Linux and Windows at launch

Your laptop

  • macOS · instant copies on APFS
  • Linux · instant on Btrfs and XFS; ext4 copies, with a warning and the time it took
  • Windows · fastest on a Windows 11 Dev Drive; regular NTFS drives work too
  • WSL2 · uses the Linux build

one line in the setup script

Cloud agent sandboxes

  • Claude Code on the web
  • Codex cloud
  • Cursor
  • GitHub Copilot
  • Jules and Devin

lane promote opens the pull request there

Where your code lives

  • GitHub · first
  • GitLab · next
  • Bitbucket · next

From install to your first lane.

Lanes finds your stack and sets up the agents you already use. A lane is a normal folder, so your editor, compiler and test runner all just work.

Star on GitHubRead the README

macOS, Linux and Windows at launch.

  • Claude Code
  • Cursor
  • Codex
  • Gemini CLI
  • GitHub Copilot
  • Conductor
  • Amp
  • OpenCode
  • Cline
  • Aider
Terminal~/your-repo
  1. 1brew install laneor cargo install lane
  2. 2cd your-repo && lane initfinds your stack and sets up your agents
  3. 3lane new fix-autha ready-to-run lane
  4. 4lane exec fix-auth -- npm run devthen open http://fix-auth.localhost

The Lanes gateway.

An optional bridge for teams, arriving in December. Run lane login, choose which repos to connect, and their lanes reach Autter through the gateway.

The Lanes gatewayLanes on your machine connect through the opt-in Lanes gateway to Autter, which gives you repo Q&A, security checks while agents work, a safe-to-merge verdict on every PR, and repo access for cloud agents and CI without cloning.fix-authadd-testsnew-billingopt-in, per repolane loginARepo Q&ABSecurity checks while agents workCA safe-to-merge verdict on every PRDCloud agents and CI without cloning
  1. Your machineYour lanesfix-auth, add-tests, new-billing
  2. Opt-in, per repoLanes gatewaylane login, then choose repos
  3. AutterChecks every laneRepo Q&A, Security checks while agents work, A safe-to-merge verdict on every PR, Cloud agents and CI without cloning

You never need Autter to use Lanes. Lanes is, and always will be, maintained as its own open source project. Repos you don't connect never leave your machine.

More about the gateway

How an Autter review runs on a lane.

Autter's reviews are hosted entirely in its cloud. Your lane stays on your machine, and the gateway lets the review read what changed.

Your machine

fix-authClaude Code
  • src/auth.ts+38 −6
  • src/session.ts+4 −1

Findings on this lane

  • 2 review comments
  • No security issues
  • Tests pass
  • Safe to merge

Autter cloud

Review running

  • Code review
  • Security checks
  • Tests

Runs on Autter. Nothing runs on your machine.

  1. The agent works in its lane

    On your machine, as usual. Nothing extra runs locally.

  2. The gateway shares the changes

    For connected repos only, Autter's cloud reads the lane's changes through the gateway. No clone, no copy of the repo to keep in sync.

  3. Autter reviews in the cloud

    Code review, security checks and tests run on Autter, while the agent is still working.

  4. Findings come back to the lane

    Comments land on the lane and in the terminal app, and the PR gets a safe-to-merge verdict.

How it works with Autter.

Lanes keeps agents apart while they work. Autter checks what they make. Together they close the loop from an agent's first step to a verified fix in production.

  1. Write

    Agents work in lanes, on your machine or in the cloud.

  2. Check

    Autter reviews, tests and security-checks each lane in its cloud while the agent is still working.

  3. Ship

    lane promote opens one clean PR, and Autter's verdict says when it's safe to merge.

  4. Fix

    When something breaks in production, Autter traces it and the fix comes back as a new lane, which goes through the same checks.

and back to the start: the fix is a new lane

This is a direction, not a promise of dates beyond December.

What's being built.

Lanes is early and built in public. This is the order things land; follow the repo for releases.

  1. Building now

    • Instant lanes, lane init, ports and env per lane
    • The terminal app
    • Claude Code integration and the MCP server

  2. Next

    • Cursor, Codex, Gemini CLI, Copilot and other agents
    • Databases and Docker Compose per lane, *.localhost URLs
    • Undo, conflict warnings, lane race and lane promote
    • Guardrails: approval codes for protected files
    • Windows: Dev Drive and NTFS
    • Cloud agent setup lines, the GitHub Action
    • Sign-in to Autter (lane login)

  3. December

    • The Lanes gateway on Autter
    • Autter reviews on lanes

  4. After the gateway

    • Lanes your team can open
    • Agents with their own access
    • Merging after checks