All releases.

GitHub Copilot on Windows, fixed. Copilot's hooks on Windows do nothing when lane isn't there, so removing Lanes no longer leaves the Copilot CLI turning down every tool, and VS Code on Windows now turns down copies of the repo like everywhere else. Still a preview.

``sh lane setup --yes # on Windows, writes Copilot's hooks again after you upgrade ``

In this version:

• Copilot's hooks on Windows run lane by its full path and do nothing if it has gone, the same in cmd.exe, Windows PowerShell and PowerShell 7. An editor started before Lanes was installed still finds it.
• VS Code on Windows turns down copies of the repo. In 0.0.8 PowerShell turned the hook's exit 2 into 1, which VS Code takes as a warning, so copies went ahead.
• Upgrading on Windows: hooks written by 0.0.8 count as out of date. lane setup --yes, the welcome in lane and lane doctor --fix write them again, and lane doctor says when they need it. macOS and Linux keep the hooks they have.

Known issues:

• Gemini CLI and GitHub Copilot are checked against their documented hook formats, not yet in live sessions.

Not yet:

• No checkpoints or undo, no promote to a pull request, and no database per lane.

Five agents, Lanes' own tools for them, and a daemon that keeps it all in step. Gemini CLI and GitHub Copilot now put their work in lanes on their own, lane mcp gives agents tools to read the repo and make lanes, and laned makes every change to lanes and keeps the terminal app live. Still a preview.

``sh lane setup # puts Gemini CLI and GitHub Copilot in lanes too claude mcp add lanes -- lane mcp # Lanes' tools for Claude Code; any MCP client works lane daemon status # whether laned is running, and the changes it has made ``

In this version:

• Gemini CLI and GitHub Copilot (the Copilot CLI and VS Code's agent mode) put their work in lanes on their own, set up once per machine like Claude Code, Codex and Cursor. The worktrees they make become ready-to-run lanes, and copying the repo is turned down with a pointer to lane new. Their settings files keep their comments, and lane setup --yes --agents off gives each one back byte for byte.
• lane mcp: an MCP server over stdio with repo.read, repo.outline, repo.grep, lane.new and lane.list, so agents read code and make lanes through tools. Lanes adds it to no agent's settings; claude mcp add lanes -- lane mcp adds it to Claude Code.
• laned, the daemon, is the one writer. While it runs, every change to lanes, from your commands, agents' hooks or the terminal app, is made there, one at a time per repo, with your environment, and install output comes back as it happens. It keeps the terminal app live, sending only what changed. Your own commands start it; agents' sessions, hooks and CI only use it if it's running. It keeps nothing of its own, so stopping it loses nothing, and it leaves by itself after half an hour with nobody connected. lane daemon shows, starts and stops it.

Known issues:

• On Windows, removing Lanes without first running lane setup --yes --agents off leaves the Copilot CLI with a hook it can't run, and the Copilot CLI then turns down every tool. Run that command before you uninstall, or delete ~/.copilot/hooks/lanes.json.
• Gemini CLI and GitHub Copilot are checked against their documented hook formats, not yet in live sessions.

Not yet:

• No checkpoints or undo, no promote to a pull request, and no database per lane.

Setup that does the work for you, and your lanes live in the terminal app. lane init and lane doctor --fix now set things up themselves and ask Y/n where the choice is yours, and lane shows every lane live, with what lanes saved you. Still a preview.

``sh lane init # set up this repo, asking Y/n before each step, then say what's left lane doctor --fix # fix what Lanes can fix by itself, asking first lane # every lane, live, and what lanes saved you lane telemetry # exactly what the anonymous install count sends from your machine ``

In this version:

• lane init in a terminal walks through each step and asks before it: lane.toml for your team, putting this machine's agents in lanes, the Git hook, the AGENTS.md note, Claude Code for this repo, and installing dependencies ahead of time so the first lane is ready in seconds. It ends with what's left for you to do. --yes takes every default, and agents, scripts and CI are never asked anything.
• lane doctor --fix fixes agents not in lanes yet, this repo's Git hook and lanes whose folders have gone, asking first. The install scripts offer to set Lanes up when they finish.
• The terminal app lists every lane with its agent, status (running when its app answers), URL, changed files, last test run and extra disk, and updates as things change. "Saved by lanes" compares the disk lanes take with a worktree plus an install for each, and counts the installs they skipped. ? shows the keys, : or Ctrl-K opens a command palette, n makes a lane and d removes one.
• The anonymous install count is sent from this version on: once Lanes is set up and once after each upgrade, a random install id, the version, your OS and CPU type, and how you installed it. Nothing else, never from CI, and off with lane telemetry off or DO_NOT_TRACK=1. It goes to a small open-source service in this repo (services/install-count) that keeps no IP addresses.

Not yet:

• No background daemon: the terminal app reads Lanes' state every two seconds instead, and its status bar says so.
• Lanes made before 0.0.7 show no savings, because Lanes measures each lane as it makes it.
• No checkpoints or undo, no promote to a pull request, and no database per lane.

See what Lanes did, and what could stop it. Two new commands, lane doctor and lane logs. A small update to 0.0.5, and still a preview.

``sh lane doctor # what could stop lanes working, and how to fix each thing lane logs # what Lanes did: lanes made and removed, agents' hooks, installs lane logs fix-auth # only what happened to one lane ``

In this version:

• lane doctor checks your machine (Git, whether your disk clones files, free space), that lane is on PATH for agents' hooks, which agents put their work in lanes, this repo's Git hook, lanes whose folders have gone, the daemon, and recent errors. Each problem says what to do next. It exits 1 only when something must be fixed, and takes --json.
• lane logs shows what Lanes did, newest last: lanes made and removed, agents' worktrees that became lanes, copies of the repo it turned down, and dependency installs. Lanes keeps the log in a file next to its state. Inside an agent's hook, problems and install output now go there instead of into the agent's view.
• CI runs every test on Btrfs, XFS and ReFS disks too, and a lane there must be cloned, never copied.

Not yet:

• Gemini CLI, Copilot and other agents get lanes only when they make a Git worktree, through the hook lane init adds.
• There's no background daemon, no checkpoints or undo, no promote to a pull request, and no database per lane.

Your agents put their work in lanes on their own. Run lane once, and Claude Code, Codex and Cursor get a lane for each task, in every repo, ready to run. Nobody types lane new. Still a preview.

``sh lane # once: checks your machine and puts your agents in lanes cd your-repo claude -w fix-auth # or start a Codex or Cursor agent in a worktree of its own lane list # each agent's lane, with its ports and folder ``

In this version:

• Setup happens once per machine. The welcome (and lane setup --yes) adds Lanes to each agent's own user settings. It's a switch, and --agents off takes it back out exactly. Set up Lanes before 0.0.5? Run lane setup once more.
• Claude Code: claude -w, subagents and background sessions get lanes in every repo, without lane init. A lanes skill has Claude start a task in a lane of its own.
• Codex and Cursor: when a session starts in a worktree they made, it becomes a lane (codex-<id>, cursor-<id>), and the agent is told which lane it's in. In Codex, open /hooks once to trust Lanes' hooks.
• Lanes from agents are ready to run: dependencies are cloned from a clean copy, and each lane gets its own ports and .env. A repo doesn't need a lane.toml for this.
• Agents are turned down when they try to copy the repo (git worktree add, a git clone of it, cp -r), with a pointer to lane new.
• lane init handles repos whose Git hooks belong to Husky or lefthook.

Not yet:

• Gemini CLI, Copilot and other agents get lanes only when they make a Git worktree, through the hook lane init adds.
• There's no background daemon, no checkpoints or undo, no promote to a pull request, and no database per lane.

Claude Code works in lanes. Run lane init once, then claude -w <name> starts a session in a lane of its own, with its own ports. Still a preview.

``sh cd your-repo lane init # writes lane.toml, and sets up Claude Code's hooks claude -w fix-auth # a new lane; the session starts in it with PORT and LANE_URL set lane list # fix-auth, with its ports and folder ``

In this version:

• claude -w <name> makes a lane and works in it. Subagents with isolation: worktree and background sessions get lanes too, and removing the worktree removes the lane.
• A session in a lane starts with PORT, VITE_PORT and LANE_URL set, and knows which lane it's in.
• If Claude Code tries git worktree add in a Lanes repo, it's pointed to lane new instead.
• lane init puts Claude Code's hooks in .claude/settings.local.json, which stays on your machine and out of Git. It also adds a Git hook that turns any other tool's new worktree into a lane, and a short note in AGENTS.md. --no-agents skips all of it.
• For every repo at once, there's a Claude Code plugin: /plugin marketplace add Autter-dev/lanes, then /plugin install lanes@autter.

Not yet:

• Other agents (Cursor, Codex, Gemini CLI, Copilot) get lanes only through the Git hook: no session context and no git worktree add deny.
• Repos with Git hooks under core.hooksPath (Husky, lefthook) don't get the Git hook yet; lane init says so.
• There's no background daemon, no checkpoints or undo, no promote to a pull request, and no database per lane.

Lanes now tells you what to run next. A small update to 0.0.2, for testers.

``sh lane new fix-auth # Made lane fix-auth in 0.4 s ... # Next: # cd ~/code/app.lanes/fix-auth start your agent here, so it works only in this lane # lane exec fix-auth -- npm run dev -- --port 4100 run the app at http://fix-auth.localhost:4100 ``

In this version:

• lane new, lane adopt, lane init, lane rm and an empty lane list end with a short "Next:" block. It names the lane's own folder, dev command and URL. With --json, the same steps are in next, so agents can follow them too.
• The home screen lists your lanes with their URLs, and says what to do next: lane init in a repo that isn't set up yet, lane new in one with no lanes.
• The welcome's last screen no longer calls lane init and lane new "soon".
• lane --help starts you off in three commands.
• The download page puts the quickest install for your system at the top.

The lane commands work: try them on your own repo. Still a preview: agents don't land in lanes on their own yet, which comes next.

``sh cd your-repo lane init # writes lane.toml from what it finds lane new fix-auth # an instant, ready-to-run copy with its own ports lane exec fix-auth -- npm run dev lane list lane rm fix-auth ``

In this version:

• lane new <name> makes a lane from a clean copy of main, with dependencies installed once.
• It's a real Git worktree: git status and git diff work there, and no branch is created.
• Files are copy-on-write clones on APFS, Btrfs, XFS and Windows Dev Drives, and plain copies elsewhere, with a note saying so.
• lane exec, lane env, lane list, lane rm and lane adopt all work.
• Each lane gets its own PORT, VITE_PORT and LANE_URL (http://<name>.localhost:<port>), so two lanes can run the same dev server at once.
• lane init finds your package manager, dev command and .env template, and writes lane.toml.
• Every command has --json and stable exit codes. Writes take --request-id, so a retried command never makes a second lane.

Not yet:

• Agents don't land in lanes on their own: start them inside a lane's folder for now.
• There's no background daemon, no checkpoints or undo, and no promote to a pull request.
• There's no database or Compose project per lane.
• *.localhost URLs work in browsers and curl, but not in every Windows tool.

The first preview. In this version:

• lane opens the first-run welcome, then the home screen.
• lane setup checks your machine, walks you through fixes, and saves your settings (also with --json).
• --help and --version work.
• The lane commands (init, new, list, exec, rm) are listed but not built yet, and exit with code 3.

It runs on macOS, Linux and Windows, on x64 and arm64.