Harness

A harness is the coding CLI that Lanes runs in its embedded terminal. Lanes reads session state from what the CLI writes to disk, so having one installed is the only setup needed. Two are supported today: Claude Code and OpenAI Codex.

Open Settings, then Agentic Coding, then Harness.

What the Page Shows

One card per CLI, under Available CLIs:

• PATH status -- On PATH or Not on PATH, resolved with command -v.
• Version -- what the CLI itself reports when asked.
• Install path and manager -- the resolved binary path, followed by whichever package manager put it there: npm global, bun global, pnpm global, yarn global, Homebrew, native installer, or unrecognised install.
• Update availability -- an amber · v2.2.0 available when a newer version exists, or · up to date when there is nothing to do.

Recheck re-runs the detection.

The path is shown for diagnosis, not for editing. Lanes launches whatever is on your PATH, so if you want a different build, change what your shell resolves.

Why the Update Verdict Is Sometimes Missing

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", never "you are behind" and never a bare claim that you are current.

Installing and Updating

Install appears only when the CLI is missing. Update appears only when it is present.

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.

Update uses the manager the CLI actually came from, which 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 would report success while the old binary kept right on running. Lanes matches the manager it detected:

Both actions run in a real terminal, so you watch the output rather than a spinner.

Improving Codex Idle Detection

The Codex card carries one extra block, Improve idle detection (optional).

Idle detection already works from Codex's rollout transcript. For a second signal, Codex can be told to write its status into the terminal title:

[tui]
terminal_title = ["status", "spinner", "project"]

Add to Codex config writes exactly that block to ~/.codex/config.toml and leaves the rest of the file untouched. Once it is there, the card reads Terminal title is configured, and Lanes reads Codex's Working and Ready title states alongside the transcript.

What Is Configured Elsewhere

This page is deliberately about detection and lifecycle. Everything else about how a session runs lives where you launch it, or on a page of its own:

• Which harness a session uses -- the Harness row in the session settings picker. See Working with Sessions.
• Model -- the Model row in the same picker.
• Flags -- the Flags row in the same picker, plus per-repository flags and environment variables in Settings.
• Where requests go -- Gateway.
• Models on your own machine -- Local LLMs.
• Terminal program -- Settings, then Agentic Coding, then Terminal.
• Folder access -- Settings, then User, then Permissions.