An account you connect becomes one connection: its own credential, its own permissions, its own label. Connect it once, and every agent you have registered can reach it.
$ lanes link connect gmail --profile personal --workspace localRun the same command again for a second mailbox. Each account is its own connection, and they do not share anything but the provider they came from.
$ lanes link status --profile personal --workspace localstatus is the answer to "what do my agents actually have". It lists every connection and what each
one makes reachable.
What you can connect
Every provider has the full catalogue, 105 of them, each one command.
If what you want is not on it, add your own: any MCP server, REST API, IMAP or CalDAV host, or local folder becomes a provider from a YAML manifest, validated by exactly the same schema as the built-in ones.
Some of what your agents reach is not an account at all. Memory, tasks, assets, skills, identity, and the vault are built in, and a new profile arrives with them already granted.
The methods behind a connection
Every connection authenticates one of a handful of ways. Which one a provider uses is the only thing that changes what connecting asks of you:
| What it means for you | |
|---|---|
| Dynamic registration | A browser opens, you approve, done. The vendor registers Lanes Link as you run the command, so there is no console to visit. Most providers work this way |
| A client we operate | A browser opens, and the OAuth client belongs to Lanes rather than to you, so no client secret of theirs sits on your machine. --own-client opts out |
| An application of your own | The vendor offers no dynamic registration, so you register once in their console. setup plan prints the exact steps |
| A token you paste | No browser, which also means it works over SSH and in a container |
| An app password | Mail, calendars, and contacts over IMAP, CalDAV, and CardDAV. Often one password covers all three |
| Nothing at all | A folder already on your machine |
| A signed handshake | A keypair rather than an OAuth flow. bunq is the one that works this way |
The catalogue is grouped by these, so you can see what a connection will cost you before you start.
See what it needs before you start
$ lanes link setup plan --profile personal --workspace local # every provider, connected or not
$ lanes link setup plan icloud_mail --profile personal --workspace local # the steps, the values, the commandAn agent connected to your endpoint can read the same thing, so it can hand you the exact command rather than guessing at one. That surface is read-only: connecting, credentials, and permissions stay in this CLI.
It works straight away
As soon as connect finishes. It saves the connection, copies the config to wherever that workspace's
endpoint reads it, and asks the endpoint to re-read it. A running lanes link start picks it up
without a restart, and a deployed endpoint picks it up without a new revision.
The last line tells you which happened, and how many tools your agents can now see:
Next: Serving it now. The endpoint has re-read its config.
42 tools are advertised now. A client connected before this keeps the
list it already fetched, so reconnect it to pick them up.If no endpoint was running, it says so instead. The connection is saved either way, and served the next time that endpoint starts.
Your agent needs reconnecting, though
An agent reads the tool list when it connects and then keeps it. Lanes Link holds no session, so there is no channel to tell it otherwise. An agent you registered before this connection still shows the tools it saw back then.
Remove it and add it again. For a hosted connector that is Disconnect and re-paste the URL; for a local one, whatever your agent's equivalent is.
To see what an agent would be handed right now:
$ lanes link tools --profile personal --workspace localIf that count matches your agent, its tools are current. If not, reconnect it.
Skills are a special case: a skill is a prompt rather than a tool, so adding one
moves no counter and nothing announces it. After lanes link skills add, reconnect on the same
reasoning without waiting for a number to change.
Narrowing what an agent may do
Connecting grants a read bundle. Tightening it is instant and happens on your machine:
$ lanes link policy deny gmail.send --profile personal --workspace localA deny always beats an allow, whatever the order in the file. Widening what the vendor permits is a different matter and needs browser re-consent.
Scopes and permissions has both directions, what a bundle is, and why a rule cannot name a single connection.
Connecting without a terminal to answer
Where the credential is a key or a password rather than a browser sign-in, an agent with a shell can do the whole setup:
$ printf %s "$TOKEN" | lanes link secrets set github/octocat --profile personal
$ lanes link connect github --id octocat --non-interactive --json --profile personal--non-interactive never prompts. It resolves every value from the credential store, or refuses and
prints exactly what is missing and the command that stores it. Anything that needs a browser is
refused outright rather than opening a window nobody is watching.
Credentials go in on stdin, never as a flag. An argument lands in your shell history, in ps output,
and in any transcript.
Next: every provider, then Add it to your agent and Deploy to your own cloud when you want it reachable from a phone.