Lanes
GitHub

Guide · Claude Code

Multiple Claude Code sessions in the same repo

In shortYou can run several Claude Code sessions in one repository, but they do not know about each other. In one checkout they overwrite each other's edits; in separate worktrees they collide at merge time instead. To run them safely, give each session its own worktree or clone and add a coordination layer such as Lanes, whose hooks make edits to the same file take turns and tell each session what the others are changing.

Updated 2026-11-12 · Lanes 0.3.0 · Source on GitHub

Why run several sessions

A single Claude Code session works on one task at a time. Running three sessions in parallel, one on the API, one on the UI and one on the tests, gets more done, and on a team every developer already runs their own. Either way, several agents end up writing to one codebase at once.

What goes wrong

Claude Code sessions do not know about each other. Each one reads the code when it needs it and writes back its own version.

In one checkout, two sessions editing the same file overwrite each other. The second write wins, and the first session's change disappears, usually without an error.

In separate worktrees, files on disk are safe, but the sessions' changes meet when you merge. A session that called a function another session renamed produces code that no longer builds, and neither session knew.

Across a team, the same happens between people's machines, with less visibility: you learn about a teammate's overlapping work from a merge conflict.

A setup that works

  1. Give each session its own checkout. For parallel sessions on one machine, use worktrees:
git worktree add ../app-ui -b ui-work
git worktree add ../app-tests -b test-work
  1. Install the Lanes hooks once. In the repository, run lanes init. It adds hooks to .claude/settings.json, copies the hook script into .lanes/ and commits both. Every worktree and every teammate gets them from git.
  1. Turn on shared context. Run lanes team on and commit .lanes/team.json. Each session now gets a short brief at each prompt and a heads-up before it reads or edits a file another session is changing.
  1. Start Claude Code in each checkout as usual. The first session starts a local Lanes server.
  1. Watch the sessions. lanes app opens the browser app with every session, the files it holds and what it waits for. The VS Code extension shows the same in a sidebar.

What each session sees

When two sessions want src/session.ts, the second one waits about a second, gets the first session's change synced into its checkout, then edits the current version. Claude Code shows "Lanes: coordinating with teammates…" while it waits.

When one session renames a function, the others learn about it before they call it:

Team note about "src/session.ts": Ana's agent, working on "Rename getUser to fetchUser", changed lines 12 to 30 a minute ago. If your code uses this file, write it to match that change rather than the version you see now.

Every edit is committed as you and published to lanes/main, so each session starts from the others' latest work. lanes pr later squashes one task's commits into a branch for review.

Teams

For a team, one person runs lanes server --host 0.0.0.0 and invites the others with lanes invite <name> or GitHub sign-in. Everyone's Claude Code sessions then share one view, and a teammate can send a request to your session that runs only after you approve it.

The full Claude Code integration, every hook and what it does, is on the Claude Code page.

Questions

Can two Claude Code sessions share one checkout?

They can, and with Lanes their edits to one file take turns instead of overwriting. Separate worktrees are still better: each session's builds, tests and half-finished work stay out of the others' way.

Does each session need its own Lanes server?

No. Every session on a machine uses the same local server, which starts by itself with the first session. A team points every machine at one server.

Will Claude Code ask me questions about Lanes?

No. The agent learns once that its edits are committed automatically. It is never told to stop or to ask you. In the benchmark, 1 of 216 sessions asked its user anything.