Quick start

Six commands to an endpoint every agent you use can reach. You need Bun 1.3.11+. There is no build step.

1. Install

$ bun install -g @lanes-sh/link
$ lanes --version

Run that second line. If lanes is not on your PATH, later commands fail with a 401 that looks like a bad token.

2. Sign in

$ lanes auth login
ok    signed in as [email protected]

3. Create a profile

A profile decides which of your connections an agent reaches, what it may do with each, and who may use it. Most people start with one. Access Profiles covers them properly.

$ lanes link profile add personal
ok    created profile personal
      config   ~/.lanes-link/profiles/personal/profile.yaml
      port     7337

That puts you on the profile as its owner, which is what makes it reachable: an empty members list means nobody, not everybody.

4. Start the endpoint

$ lanes link start
ok    serving http://127.0.0.1:7337/mcp
      profiles: personal
Ctrl-C to stop.

Leave it running.

5. Register it with your agents

In another shell:

$ lanes link mcp add
ok    registered lanes-link with Claude Code (user scope)
      installed skill at ~/.claude/skills/lanes-link/SKILL.md
ok    registered lanes-link with Codex

With no argument that covers every agent you have installed, or name one: claude, codex.

Codex needs one extra line, and Claude Desktop is set up by hand because it cannot be given a URL. See Add it to your agent.

Your memory, tasks, assets, skills, entities and vault work now. They hold your own material rather than an account, so there was never anything to authorise. Try it:

$ lanes link tasks add "chase the invoice" --due 2026-09-01 --profile personal
ok    added task chase-the-invoice

6. Connect your first account

A mail or calendar account is the first thing that needs any setup:

$ lanes link connect gmail

That opens a browser and nothing else. Google authorises against the OAuth client Lanes operates, so there is no Cloud project to create. The connection is served straight away, with nothing to restart. The agent you registered in step 5 keeps the tool list it read then, so Gmail's own tools appear when it next re-reads; it can reach the account before that with lanes_tools_search.

Connect your accounts covers everything you can connect and what each one needs.

Check what you have

$ lanes link status                 # connections, capabilities, endpoint
$ lanes link audit tail --limit 25  # what your agents have actually done
$ lanes link policy list --profile personal   # what they are allowed to do

Ask an agent to search your mail. If it is refused, that is the permission system working. Run lanes link policy list and widen it deliberately.

Next: Connect your accounts.

Notes

Which store a thing goes in. Nothing refuses the wrong choice, so it is worth knowing. Memory is what is true, tasks is what is to be done, assets is a file. "Remember to chase the invoice" is a task; filed as memory it becomes a note nothing can ever close. Your agents are told this too. Built-ins covers all of them, and how to make memory read-only.

Why the sign-in. A profile declares who may consume it, and the endpoint cannot check that against anything if it does not know who is asking. The network is needed to sign in and to refresh, not per call: a machine offline for a day keeps serving, and lanes auth status says how long that has left.

No --workspace flag here. A workspace holds your connections and your profiles and decides which stores open them. A fresh config sets default_workspace: local, so every command above resolves to it and prints which one it got. Name it explicitly with --workspace, and note that commands which publish or destroy (deploy, sync, secrets push, profile remove, disconnect, token rotate) refuse the default and make you type it. lanes link workspace list shows what you have.

Two profiles side by side. Each profile keeps its own memory, tasks, assets, skills, entities and vault, plus its own grants deciding which of the workspace's accounts it reaches. The credential store and the audit log belong to the workspace, so both profiles share those.

$ lanes link profile add work
$ lanes link connect notion --id acme
$ lanes link grant add notion.acme --profile work
$ lanes link start
ok    serving http://127.0.0.1:7337/mcp
      profiles: personal, work

One endpoint serves both, and each call names the profile it means. They share that endpoint's token, so an agent holding it can reach either by asking. For a boundary that holds against the agent itself, use a second workspace.

Keeping it current. lanes link update installs a newer release, and lanes link update --check only says whether there is one.

Working on Lanes Link rather than using it? Local development has the checkout.