Keep your coding CLIs current

Lanes runs the official coding CLIs in a real terminal, so having one installed is the entire setup. The catch is that "installed" is a fuzzier state than it sounds: there may be two copies on the machine, the one on your PATH may not be the one you think, and the update command you reach for may be updating a copy that never runs.

The Harness page makes that state visible for Claude Code and OpenAI Codex, and keeps it current from the same screen.

How Lanes does it

PATH status and version. Resolved with command -v, alongside whatever version the CLI itself reports when asked. No guessing from a lockfile.
The resolved path, and who put it there. The binary path plus the package manager behind it: npm global, bun global, pnpm global, yarn global, Homebrew, a native installer, or an unrecognised install. The path is shown for diagnosis, not for editing. Lanes launches whatever your PATH resolves, so if you want a different build, change what your shell resolves.
Updates through the right manager. This is the part that matters more than it sounds. bun, pnpm, and yarn each keep global packages in their own prefix, so running npm install -g against a bun-installed CLI reports success while the old binary keeps right on running. Lanes matches what it detected: bun add -g for bun, pnpm add -g for pnpm, brew upgrade --cask for Homebrew, claude update for a native Claude Code install.
Install only when it is missing. Install prefers Homebrew when it is available and falls back to npm. Homebrew goes first because it matches how Lanes itself installs, it is revertible, and it avoids piping a downloaded script into a shell.
Both actions run in a real terminal. You watch the output rather than a spinner, and if something goes wrong you have the error rather than a red toast.

No verdict beats a wrong verdict

Lanes reads the latest published version from the package registry. If the registry cannot be reached, because you are offline or it is having a bad day, the card shows your installed version and offers no verdict at all.

An unreachable registry means "no update to offer". It never means "you are behind", and it never becomes a bare claim that you are up to date. up to date is shown only when there was a real answer to compare against, which is the only way that label is worth anything.

Why it matters

Version drift is quiet. A CLI that is four releases old still starts, still answers, and still writes files; it just does not have the model you thought you were selecting, or the flag your teammate's setup depends on. When you are running several sessions at once, that drift is multiplied across every agent on the board, and the symptom shows up as "the agent is being weird today" rather than as a version number.

The manager-mismatch trap is the same problem with a sharper edge, because it produces a successful-looking update that changes nothing. Detecting the manager and using it removes a class of confusion that is genuinely hard to debug from the outside.

Set it up

Install Lanes and open it:

Bash

brew install --cask lanes-sh/lanes/lanes && open -a Lanes

Then:

Open Settings, Agentic Coding, Harness. One card per CLI, with PATH status, version, resolved path, and detected manager.
Act on the amber chip. · v2.2.0 available means there is a newer release; Update runs the right command in a terminal you can read.
Use Recheck after anything external. Installing a CLI outside Lanes, or switching Node versions, changes what your PATH resolves.

If you run Codex, the card also carries an optional one-click block that adds [tui] terminal_title to ~/.codex/config.toml. Idle detection already works from Codex's transcript; this adds a second signal, and Lanes writes only that block and leaves the rest of the file alone.

How Lanes does it

No verdict beats a wrong verdict

Why it matters

Set it up

Further reading