Skip to content

Lanes 0.0.2 (preview)

Choose a tag to compare

@github-actions github-actions released this 17 Oct 15:23
· 88 commits to main since this release

Install or update:

On Command
macOS, Linux, WSL brew install autter-dev/tap/lanes, or curl -fsSL https://github.com/Autter-dev/lanes/releases/latest/download/lanes-installer.sh | sh
Windows winget install Autter.Lanes, scoop install lanes (after scoop bucket add autter https://github.com/Autter-dev/scoop-bucket), or irm https://github.com/Autter-dev/lanes/releases/latest/download/lanes-installer.ps1 | iex
Anywhere with Node npm install -g @autter/lanes

More ways, and how to check a download, at https://lanes.autter.dev/download.

Verify an archive: gh attestation verify <file> --repo Autter-dev/lanes, or compare it with SHA256SUMS.

Changes

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.

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.

2026-10-17

  • 15:07 Added: lanes run things. Every command in the CLI now works.
    • lane exec [<name>] -- <command>: runs a command in a lane with its own ports and URL. PORT, VITE_PORT, LANE_URL, LANE_NAME, LANE_ID, LANE_PORTS and LANE_PATH are set.
      • $PORT, ${PORT} and %PORT% in arguments are filled in without a shell.
      • It exits with the command's own code.
      • On Windows it finds npm-style .cmd and .ps1 launchers.
      • Inside a lane, the name is optional.
      • Two lanes ran the same dev server at once on ports 4100 and 4110.
    • lane env [<name>]: prints those variables for sh, PowerShell, cmd or dotenv, or as --json.
    • lane init: looks at the repo and writes a commented lane.toml, running and installing nothing. --print and --force are there too.
      • It finds the package manager (pnpm, npm, Yarn, Bun, uv, Poetry, Bundler, Go, Cargo), the dev command and its usual port, the .env template, a Compose file and migration tools (Prisma, Drizzle, Rails, Django, Alembic).
      • Frameworks that don't read PORT get --port $PORT.
    • The lane's .env: a lane gets one from [env] template, with its own PORT and LANE_URL and every other line kept.
    • [dev] command in lane.toml.
  • 14:21 Added: the lane engine: lane new, lane rm and lane adopt work.
    • lane new <name>: makes a lane from a clean _base copy of the base branch (main), with dependencies installed once from [setup] install in lane.toml.
      • Files are cloned where the disk can, and copied otherwise, with a note saying so.
      • The lane is a real Git worktree on a detached HEAD: git status and git diff work there at once, and no branch is created.
      • Each lane gets its own block of ports.
      • _base follows main, and reinstalls only when a lockfile or the install commands change.
      • Python virtualenv paths are pointed at the lane.
      • --print-path prints just the folder, for agent hooks.
    • lane rm <name>: removes the folder and worktree record and frees the ports. --keep-files keeps the folder.
    • lane adopt [<path>]: turns a worktree you already have into a lane.
    • Retries and failures: all three take --json and --request-id. A failed lane new removes everything it made, so a retry starts clean.
    • lane list: shows each lane's state, and works from inside a lane too.
  • 14:05 Added: clone backends, the part of lane new that copies files.
    • How it copies: every file is a copy-on-write clone where the disk supports it (APFS, Btrfs, XFS, and ReFS on a Windows Dev Drive), and a plain parallel copy everywhere else (NTFS, ext4, …), behind one CloneBackend trait.
    • Probe and report: a probe tests each folder for real, and the report counts cloned, copied and empty files separately, so Lanes never claims a clone it didn't get.
    • Faithful copies: modification times and permissions are kept, so builds don't redo everything, and symlinks stay symlinks.
    • Measured on a 13,826-file tree (this repo plus the website's node_modules, 247 MB):
      • Windows Dev Drive: about 2.7 s per lane, every file cloned, about 120 MB of disk per lane;
      • NTFS plain copy: 7.6 s and a full copy.
    • New CI job: runs the clone tests on Btrfs and XFS loop disks and a ReFS virtual disk; APFS is covered by the macOS job.
  • 13:33 Added: the foundations the lane engine builds on, plus lane list.
    • Errors: one error type for every command. Each has a stable code, its exit code and a hint saying what to do next.
    • --json contract: exactly one JSON object on stdout, the result or {"error": {code, message, hint, exit}}, and nothing else. Unbuilt and unknown commands answer the same way.
    • lane.toml v1: [lanes], [ports], [setup], [env] and [cleanup]. A missing file means the defaults; typos and files from a newer Lanes are refused with what to fix.
    • State store: per-user SQLite (WAL mode) with a single-writer lock, so port blocks never clash across repos. Reads never create files.
    • --request-id / LANE_REQUEST_ID: a retried write returns the first result instead of running twice.
    • lane list: shows this repo's lanes (--all for every repo) with their ports, and has --json.
    • The minimum Rust version is now 1.89.
  • 13:25 Changed: AGENTS.md names the anonymous install count as the one exception to "no network calls unless the user ran lane login". It's on by default, opt-out with lane telemetry off, LANE_TELEMETRY=0 or DO_NOT_TRACK=1, and never sent from CI. Nothing sends it yet.
  • 12:34 Added: the download page says up front that builds aren't code-signed yet, and what that means on each system. macOS needs one xattr command, only for archives downloaded in a browser. Windows 11 with Smart App Control on may block lane.exe (WSL2 works meanwhile). Linux needs nothing extra.
  • 11:47 Added: an "All releases" page at lanes.autter.dev/download/releases. It lists every version, newest first, with its summary, the six archives and their checksums, the installers, a link to the release notes, and the command to install that exact version. The download page has a "Past releases" list linking to it, and the footer links it too. On phones, file tables stack one file per row.
  • 11:42 Added: Lanes is on npm: npm install -g @autter/lanes installs only the build for your system, with signed provenance. A new npm workflow publishes an existing release from its own archives, and the installers check now installs through every live channel (both scripts, Homebrew, Scoop and npm) on macOS, Linux and Windows. The download page lists npm as live; winget is still waiting for Microsoft's review.
  • 11:19 Added: Lanes 0.0.1 is out as a preview. It installs with brew install autter-dev/tap/lanes, with Scoop from the Autter bucket, with the one-line scripts (curl -fsSL https://lanes.autter.dev/install.sh | sh, irm https://lanes.autter.dev/install.ps1 | iex), or from GitHub Releases. Each one was checked by a real install on macOS, Linux and Windows. The download page and the README show the live options; npm and winget are marked "coming soon" until they're published. A new installers check reinstalls every release the way users do.