Lanes Link

Lanes Link is one MCP endpoint you run yourself. It holds your accounts, your memory, the skills you reuse, and the credentials you would rather not paste into a prompt, and it decides what each agent may do with them. It is a separate product from the desktop app, with its own repository, its own CLI, and its own release line.

Since v0.47.0, Lanes can drive it for you. The Lanes Link page installs the CLI, holds the profile and target every command runs against, connects accounts, starts and stops the endpoint, and registers it with Claude Code or Codex. The page is native UI over the lanes CLI: it runs the commands you would otherwise type, and shows you what the CLI reports back.

It carries a Research Preview badge. The feature is new and its shape may still move.

Where to Find It

Open Settings, then Integrations, then Lanes Link. There is also a Link row in the sidebar that jumps straight there.

If you already have the CLI, lanes link desktop opens this page from a terminal. It is a deep link under the hood, and needs Lanes 0.48.0 or newer.

If you are weighing Lanes Link against the other two Lanes MCP servers, MCP compares all three side by side.

Installing the CLI

The first card on the page is the CLI itself. It shows whether lanes is On PATH, which version you have, whether a newer one is available, where it is installed, and which package manager put it there (bun global, npm global, Homebrew, native installer, or unrecognised install). Install, Update, and Recheck sit alongside.

Bun is the only installer Lanes Link supports, so Install runs:

console

$ bun install -g @lanes-sh/link

If Bun itself is missing but Homebrew is present, the same button installs Bun first. If neither is there, Lanes explains what to do instead of piping a downloaded script into your shell:

Needs Bun, which Lanes Link requires and this machine doesn't have. Install Bun from bun.sh, then come back.

Two cases the card calls out:

You installed from a checkout. Lanes says so, because git pull is the update there, not a package manager.
Nothing else on the page appears yet. Everything below the card stays hidden until the CLI is actually installed. There is nothing to configure without it.

You usually will not press it

Lanes runs that install for you. Installing the app installs the CLI, and updating the app updates it — so on most machines the card is already green the first time you open this page, and the buttons are there for the times it is not.

It runs once per launch, and only when the app's version has changed since it last did: a fresh install, or the first launch after an update. There is no polling, and nothing reinstalls a CLI you removed on purpose until the app next updates. The command runs in a real terminal you can open from the sidebar while it works, and Auto-Update in Settings → General is the switch — the same one that lets the app replace itself.

Two cases it leaves alone. A checkout install is never touched, because git pull is the update there. And a machine with neither Bun nor Homebrew has no command to run, so nothing happens and the card says what to do.

If a copy installed by npm, pnpm or yarn is in the way, Lanes removes it and installs with Bun, so you are left with one lanes rather than two and no question about which one your shell picks.

Choosing a Profile and Target

A profile is one set of connections. A target is where that profile runs and which credential store it opens. Lanes Link picks neither for you, so the desktop app owns the pair and passes --profile and --target on every command it runs. The two dropdowns at the top of the Connections section are that choice.

Targets read as local (file) or cloud (deployed to cloudrun). Your selection is saved in the app's integrations.json, so it survives a restart.

Keeping work and personal in separate profiles is the point of the design: every call an agent makes carries the profile, so the two never depend on remembering which context you are in.

Connecting an Account

Click Add new connection. A dialog opens with a Filter providers box and every provider Lanes Link supports, each showing how many accounts you already have connected to it.

Pick one and Lanes runs lanes link connect for that provider against the selected profile and target, in a real terminal inside the app. Your browser opens for consent, and the credential is written to that target's store.

Some providers have no endpoint that can say whose account a credential belongs to. For those, Lanes asks for a short name first (lowercase letters, digits, and underscores) and shows you the resulting connection key as you type, for example gmail.main.

The exchange stays with the CLI on purpose. Lanes starts the command and shows you its output; it does not implement the OAuth flow itself, and it never sees the token.

Reading Connection State

Each connection row shows the provider, its key, the account, and a state pill:

Pill	What it means
`active`	Declared, and this target holds what it needs.
`unauthorized`	Declared, but the credential is missing from this target's store. Repair re-runs connect.
`not synced`	Declared, but this target's state store has not seen it yet. Starting the endpoint reconciles it.
`disabled`	Present in the state store but no longer declared in this profile.

The row's menu offers Repair when there is something to repair, and Show profile file always. There is deliberately no Remove action: a connection is declared in the profile file, so removing one is an edit to that file, which the CLI owns.

Starting the Endpoint

The endpoint row shows the URL and whether it is answering: Running, Deployed and answering, or Not answering, with the profiles it serves underneath. Start, Log, Stop, and Recheck act on it.

Start runs lanes link start for the current selection in a long-lived terminal that Lanes keeps around. Log opens that terminal so you can read it; closing the window leaves the endpoint running. Stop shuts it down.

Two things worth knowing:

Lanes serves one selection at a time. If you switch profile or target while an endpoint is up, the page tells you which one it is currently running and asks you to stop it before serving the new selection.
Deployed targets have no Start button. A cloud target is already running somewhere else; Lanes only reports whether it answers.

Registering an Agent

The Agent clients section has a row per harness Lanes can register for you, Claude Code and Codex, each showing whether it is installed and whether its registration is current. The button reads Add to Claude Code when it is not registered, Update files when the skill or scout agent has gone out of date, and Re-add when everything is current. Running it again is safe, and worth doing when a skill is stale.

Registering does three things:

Points the harness at your endpoint, under the server name lanes-link, at Claude Code's user scope. Your accounts are not one repository's tooling, so the registration is not bound to a project or a worktree.
Installs a skill at ~/.claude/skills/lanes-link/SKILL.md that tells the agent what is behind the endpoint.
Installs a lanes-link-scout subagent at ~/.claude/agents/lanes-link-scout.md.

The secondary No skill button registers the endpoint without touching the agent's own skill files.

Because the registration lives at user scope, every session Lanes starts picks the tools up automatically. There is nothing to switch on per session.

Any Other Client

Expand Another client for the two facts any MCP client needs, a URL and a bearer token:

console

$ claude mcp add --transport http lanes-link http://127.0.0.1:7337/mcp \
    --header "Authorization: Bearer $(lanes link token show --raw --profile personal --target local)"

Copy that line as it is. The $(...) is load bearing: it keeps the token out of the agent's context and out of your transcript. Lanes never reads the token either.

What Lanes Does Not Do

The boundary between the app and the CLI is deliberate, and worth knowing before you debug something:

Lanes never reads your bearer token. The command that would print it exists and is not called.
Lanes does not write MCP config. lanes link mcp add runs each harness's own registration command, because the config format is that agent's business.
Lanes does not implement OAuth. The CLI owns the loopback listener and the browser consent.
Lanes does not edit your profile file. It reads it, shows it to you, and opens it.

So anything you set up here works the same from a terminal, and anything you set up from a terminal shows up here.

Running Lanes Link On Its Own

You do not need the desktop app. Lanes Link is a standalone, Apache-2.0 CLI, documented in full at Lanes Link docs, with its source in lanes-sh/link:

Quickstart, from nothing to a working endpoint.
Connections, what a connection is and the methods behind one.
Every provider, all 105 and what each one needs.
Add it to your agent, Claude Code, Codex, Claude Desktop, claude.ai, and ChatGPT.
Deploy to your own cloud, five commands to a URL.

The announcement post covers the permission model, profiles, and the audit log in depth.