Lanes Link shipped in August as a CLI: one MCP endpoint you run yourself, holding your accounts, your memory, the skills you reuse, and your secrets, with a permission model that decides what each agent may do with them. Setting it up meant a terminal, six or seven commands, and knowing which profile and target each of them applied to.
From v0.47.0, the desktop app does that part for you.
Open Settings, then Integrations, then Lanes Link, or use the Link shortcut in the sidebar.
Four steps, no terminal
Install the CLI. The first card tells you whether lanes is on your PATH, which version
you have, whether a newer one exists, and which package manager installed it. One button
runs bun install -g @lanes-sh/link, or installs Bun via Homebrew first if you need it.
Nothing else on the page appears until the CLI is really there.
Pick a profile and a target. A profile is one set of connections; a target is where it runs and which credential store it opens. Lanes Link resolves neither for you by design, so the app holds the pair and passes it on every command. That choice persists, so work and personal stay properly separate rather than depending on what you last typed.
Connect your accounts. Filter the provider list, click one, and Lanes runs the connect command in a real terminal inside the app. Your browser opens for consent. Each connection then carries a state you can read at a glance: whether this target actually holds the credential, whether the endpoint has reconciled it yet, and whether repairing it means re-running connect.
Register your agents. One button points Claude Code or Codex at the endpoint and installs the skill that tells the agent what is behind it, plus a scout subagent for wide reads across your context. It registers at user scope, because your accounts are not one repository's tooling. Every session Lanes starts picks the tools up from there.
Native UI over the CLI
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, which is what keeps the two halves interchangeable:
anything you set up in the app works from a terminal afterwards, and anything you set up in a
terminal shows up in the app.
Consent and the bearer token stay with the CLI. The command that would print the token exists,
and the app leaves it alone. When you register a client by hand, the snippet it gives you keeps
the token inside a $(...), so it stays out of the agent's context and out of your transcript.
OAuth belongs to the CLI too: it owns the loopback listener and the browser consent, exactly as
it does from a terminal.
Registration goes through each harness's own command rather than a config file Lanes writes, because the config format is that agent's business.
Open source, and what comes next
Lanes Link is a standalone, Apache-2.0 project with its own repository and its own release line. You do not need the desktop app to run it, and its full documentation lives with the source at lanes-sh/link.
Providers are additive by design, so a new one lands without touching the core, and
docs/creating-a-provider.md is written to be enough on its own. Provider proposals, issues,
and pull requests are all welcome.
The page is new and its shape may still move, particularly around how profiles and targets are presented. So tell us: which providers you want next, and where the flow gets in your way. Join our Discord, or open an issue on the repo.
The Lanes Link docs cover the desktop page in full, from the connection states to the manual registration snippet. If you are new to Lanes Link, the announcement post covers the permission model, profiles, and the audit log in depth.