Quickstart

From nothing to an endpoint your agents can use. Steps 1 to 5 need no external service, no credentials, and no account anywhere. The first thing that costs any setup is step 6.

You need Bun 1.3.11+. There is no build step.

1. Install

console

$ bun install -g @lanes-sh/link
$ lanes --version             # confirms it landed on your PATH

Check that second line. Several registration commands read your token with $(lanes link token show --raw), and without lanes on your PATH that substitutes to an empty string. The only symptom is a 401 that looks like a bad token.

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

2. Sign in

Every human caller signs in with Lanes, on your own machine as much as on a deployed endpoint. A profile declares who may consume it, and there is nothing to check that against if the endpoint has no idea who is asking.

console

$ lanes auth login
ok    signed in as you@example.com
      subject  lanes:3QBmAxJLLrYSMTVUIeCN1SKFbdD3

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 to run.

3. Create a profile

A profile is a selection: which of your connections it includes, what it allows on each, and who may consume it. Most people start with one.

console

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

$ lanes link profile members add --me --profile personal --workspace local
ok    you may now consume personal as owner

That second command is not optional. Empty members means nobody, which is the opposite of how a blank list reads, so the profile you just created reaches no one until you are on it.

4. Your own context is already there

Memory, tasks, assets, skills, and the vault hold your material rather than an account, so they need no credential, no browser, and no command. The profile you just created declares all six.

Which store a thing goes in is worth knowing, because nothing refuses the wrong choice:


memory	what is true: a fact, a preference, how something works
tasks	what is to be done, each with a status, so it can be closed
assets	a file, kept under its own name

"Remember to chase the invoice" is a task, not a memory entry. Your agents are told this as well.

Try it:

console

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

$ lanes link tasks list --profile personal --workspace local

Tasks (1 outstanding)
  chase-the-invoice  open  chase the invoice  due 2026-09-01

Built-ins covers all of them, and how to make memory read-only.

5. Start the endpoint

console

$ lanes link start --profile personal --workspace local
profile personal  workspace local  ~/.lanes-link
  + memory.main  create (active)
  + tasks.main  create (active)
  + assets.main  create (active)
  + skills.main  create (active)
  + vault.main  create (active)
  + setup.main  create (active)
ok    reconciled
warn  minted a token. Run: lanes link outputs --show
ok    serving http://127.0.0.1:7337/mcp
      profiles: personal
Ctrl-C to stop.

Leave it running. The token minted on that first start is for CI, which has no browser: your agents sign themselves in instead, and the next step is what points them here.

Every command prints the profile and workspace it resolved before it acts. That first line is how you know you are operating on the instance you meant, and it is worth reading when you have set a default with lanes set-workspace.

A workspace holds your connections and your profiles, and decides which stores open them. local keeps credentials in an encrypted file and data in a directory; a deployed workspace keeps them in your cloud instead. lanes link workspace list shows what you have.

("Target" was the word for this until 0.8.0. --target still works and warns.)

6. Register it with your agents

In another shell:

console

$ lanes link mcp add --profile personal --workspace local
ok    registered lanes-link with Claude Code (user scope)
      installed skill at ~/.claude/skills/lanes-link/SKILL.md
      installed scout agent at ~/.claude/agents/lanes-link-scout.md
ok    registered lanes-link with Codex
      installed skill at ~/.codex/skills/lanes-link/SKILL.md

With no argument that covers every agent installed, or name one: claude, codex. One endpoint, one token, every profile, so you register once per agent rather than once per account.

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

6. Connect your first account

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

console

$ lanes link connect gmail --profile personal --workspace local

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: connect tells the running endpoint to re-read its config, so there is nothing to restart. If no endpoint was running, the connection is saved and served when you next start one.

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

7. Check what you have

console

$ lanes link status --profile personal --workspace local                 # connections, capabilities, endpoint
$ lanes link audit tail --profile personal --workspace local --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.

Two profiles side by side

Work and personal never share a credential store, a state store, or an audit log:

console

$ lanes link profile add work --workspace local
$ lanes link connect notion --profile work --workspace local
$ lanes link start --profile personal --workspace local
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 do share that endpoint's token, so an agent holding it can reach either by asking. If you need a boundary that holds against the agent itself, use a second workspace.

Next: Connect your accounts. Working on Lanes Link itself rather than using it? Local development has the checkout.