The Security tab sits next to General on your user settings, and it exists only on your own profile — nobody else can open it, whatever their role. Its subtitle, “Manage your connected accounts, sessions, and API tokens”, is a fair summary of what it does: it answers which accounts can sign you in, where you are currently signed in, and which programs can act as you without a browser. Those are three separate lists with nothing flowing between them, so read whichever one your question belongs to.
Connected accounts
The only connectable account is GitHub. The row shows either Not connected with a Connect GitHub button, or a green Connected badge, the date it was connected, and Disconnect.
What connecting does
Connecting attaches one GitHub identity to this Leed login, so that the GitHub button on the sign-in screen signs you in. The screen states the useful half of that plainly:
Connect GitHub to sign in with it, even when your GitHub primary email differs from your Leed email.
That clause is the reason to do it here rather than to keep guessing at the sign-in screen. On the sign-in screen GitHub has to identify you by an address; from this button you are already signed in, so the session is the proof of identity and the addresses do not have to agree. It is also the fix for the reverse problem — a GitHub account that carries several verified addresses, more than one of which is a Leed account.
Connecting here does not create anything on the published site and has nothing to do with the site’s own repository access. It only affects how you sign in.
One GitHub account, one Leed login
A GitHub account can sign in to exactly one Leed login. Connecting it to a second one is refused, with the message that names the rule:
That GitHub account is already connected to a different Leed login. A GitHub account can only sign in to one Leed account — disconnect it there first, or use a magic link here.
If you hold more than one Leed account, decide which one GitHub should open, and use magic links for the others.
Both actions need a recent sign-in
Disconnecting
Disconnect is always available. GitHub is never your last way in — a magic link needs no connected account at all — so removing it cannot lock you out. After disconnecting, the GitHub button on the sign-in screen stops working for you and you sign in by email instead.
Every message these two buttons can show
account_already_linked_to_different_user, github_email_fetch_failed, email_not_found, unable_to_link_account, SESSION_NOT_FRESH and PROVIDER_NOT_FOUND each have their own copy, plus a generic “Something went wrong. Please try again.” fallback. All six are quoted verbatim with their causes and their remedies in Sign-in Troubleshooting rather than duplicated here.
Active sessions
Every place you are signed in gets a row: the browser and operating system with their icons, the IP address the session was created from, and how long ago that was. Sessions from Leed’s own tools are named for the tool and its version instead of a browser.
| Badge | What it means | How Leed knows |
|---|---|---|
| Current | The session you are reading this in | Its token matches the one your browser is using |
| CLI | A sign-in from the Leed command-line tool, shown as Leed CLI v | The tool identifies itself as leed-cli/<version> |
| Installer | A sign-in from the one-line installer, shown as Leed Installer v | The installer identifies itself as leed-installer/<version> |
| no badge | An ordinary browser session, named as | Read from the browser’s own identification |
Two controls end sessions:
- Revoke, on every row except the current one, ends that one session.
- Revoke All Other, in the section header, ends everything except the session you are using. It appears only when there is more than one session to end.
Both take effect immediately. A revoked session’s next request fails and whoever holds it is signed out — there is no grace period and no confirmation prompt, so read the row before you press it.
A session lasts seven days and is extended when you use Leed after a day’s gap, so an idle browser drops off this list on its own within a week. That is the same lifetime described in Signing In; signing out through the profile menu ends one session, and this list is where you end the rest.
The CLI and Installer rows come from a terminal that was approved through the device screen — CLI Authentication describes what the tool stores on the machine, and Authorizing Devices and Clients covers the approval itself.
If you lose a device
Rotating the CLI’s credentials is a command you run on a machine you do still control:
leed auth reset --all-sessionsleed auth reset revokes your CMS login session and rotates the site’s GitLab tokens in one go; --all-sessions extends the revocation to every other device you are signed in on. It cannot be undone and you will have to sign in again afterwards, which is the point. For a routine refresh that leaves your sign-in alone, leed auth rotate is the gentler sibling — both are documented on Leed auth commands.
API tokens
The screen states what these are for, and it is worth taking literally:
API tokens are used for service-to-service integrations (e.g., Salesforce webhooks, CI pipelines). The token value is shown only once at creation.
A token is a standing credential for a program. It is not how a person signs in.
Creating a token
Both fields are required, and Create Token stays disabled until you fill in each of them.
| Field or column | Required | Values | Notes |
|---|---|---|---|
| Name | Yes | Free text — the placeholder suggests e.g., Salesforce CRM | The only label you will ever have for it; name it after the thing that will use it |
| Expiration | Yes | 30 days, 60 days, 90 days, 6 months, 1 year, No expiration | Chosen at creation and fixed afterwards — to change it, revoke the token and create another |
| Status | — | Active or Revoked | See the note below: revoking removes a token rather than pausing it |
| Prefix | — | The first characters of the key, then dots | All you can ever see of the value once the panel is dismissed |
| Created | — | A date | When the token was made |
| Expires | — | A date, or No expiration | |
| Last used | — | A relative time, or Never used | The quickest way to tell whether anything is still using a token |
Copy it now
The moment the token is created, its value appears in a green panel headed “Token created — copy it now, it won’t be shown again:”, with an eye button to reveal it, a copy button, and Dismiss.
The value starts hidden behind dots and stays hidden unless you press the eye button, so it is safe to have the panel on screen while somebody is watching. Press copy rather than reveal-and-select where you can.
Revoking a token
One thing on this screen is worth knowing so it does not confuse you: the status column can display Revoked, but no button in the product produces that state. Both Revoke and the Delete button on an inactive row remove the token outright. Treat a token as either present or gone.
Tokens are not rate-limited per key, so a runaway integration will not be throttled on its way to whatever it is doing. If a token starts behaving unexpectedly, revoke it rather than waiting for a limit to catch it.
A token is not a CLI sign-in
This is the distinction people get wrong, and it costs an afternoon when they do.
| Session | API token | |
|---|---|---|
| Who it acts as | You, with your role in your active workspace | A program, using a credential you issued |
| How it is created | Signing in — a magic link, a code, Google, GitHub, or approving a device | The Create Token button on this tab |
| How long it lasts | 7 days, extended by use | Whatever expiry you chose, including never |
| Where it is listed | Active Sessions, above | API Tokens, above |
| How it is ended | Revoke, Revoke All Other, signing out, or expiry | Revoke, or expiry |
If a person needs to work from a terminal, they sign in — the CLI runs the device flow and the result lands in Active Sessions with a CLI badge. If a service needs to call Leed with nobody sitting there, it gets a token. Reach for a token when there is no human in the loop, and for a sign-in when there is.
What is not here
There is no password to change and no two-factor to enable, because Leed has neither — every way into your account is a link, a code, or a connected account, as described in Signing In.
There is also no list of the AI clients and applications you have authorized, and no way to withdraw one. A connection made on the authorization screen does not appear anywhere on this tab, and revoking your sessions does not revoke it. That gap is real, it is recorded on Known Limitations, and Authorizing Devices and Clients explains what an authorized application can reach in the meantime.