Every way into Leed is passwordless. The sign-in screen lives at /login, and which controls it shows you depends on how you arrived: an ordinary visit offers a magic link and whichever connected accounts your Leed environment has configured, while arriving from an application that wants to connect to Leed swaps the email form for a six-digit code. This page covers all four methods, where each one is offered, and what each can and cannot do.
The sign-in screen
In its normal state the screen reads Welcome back, with the subhead Pick up right where your team left off. Below that:
- Google and GitHub buttons, side by side, followed by an or with email divider.
- A Work email field.
- A Cloudflare Turnstile challenge.
- Send magic link, which stays disabled until the challenge resolves.
Underneath sit two lines of small print: We’ll email you a secure, passwordless sign-in link. and New to Leed? Create an account, which takes you to the sign-up form covered in Creating Your Account.
Which method do you get?
flowchart TD
A{How did you reach /login?} -->|"An app sent you<br/>(the URL carries client_id)"| B["One-time code<br/>+ Google + GitHub"]
A -->|"Normally"| C["Magic link<br/>+ Google + GitHub"]
B --> D["Enter the code in this tab"]
C --> E["Click the link in your email"]
D --> F["Signed in → the authorization screen"]
E --> G["Signed in → your home tab"]
C -.->|"Google, if configured"| H["Can create a login,<br/>and can link to one<br/>on a different address"]
C -.->|"GitHub, if configured"| I["Signs in existing<br/>logins only —<br/>never creates one"]
The rules that surprise people are on the two dotted edges: Google can bring a new login into existence and GitHub cannot.
Magic link
The default, and the one most people use. Type your work email, wait for the challenge, and press Send magic link. The screen changes to Check your email, naming the address you typed.
The email’s subject is Sign in to Leed and it carries a single Sign In → button. The link is good for five minutes and for one use.
The link opens in whichever browser you click it in, which is the practical way to sign in on a second machine: request the link on the laptop, open the mail on the laptop. Requesting it in one browser and clicking it in another still works — the session lands wherever the link was opened.
One-time code
The six-digit alternative. You will only meet it when an application is connecting to Leed — the sign-in screen switches to it whenever an OAuth client has sent you here, and the heading changes from Welcome back to Sign in to continue.
It has two steps:
- Email address plus the challenge, then Send Login Code. The email’s subject is Your Leed login code and it prints the digits rather than a button; the code lasts five minutes.
- The Login code field, then Verify and continue. Use a different email underneath starts over at step one.
If you reload the tab midway — which is easy to do while going to fetch the code — you come back to the code step with your address still filled in, not to the beginning.
Why a code, and not a link, when an app is connecting
An application connecting to Leed sends you to /login carrying a signed authorization request in the URL — the client’s identity, the address to return to, and a signature over the whole thing. Those parameters have to survive until you have a session, at which point Leed hands you back to the authorization endpoint and you land on the consent screen.
A magic link cannot carry them reliably. The link is opened in a new tab, minutes later, from a mail client, and the round trip re-encodes the return address, nesting the signed query inside itself and corrupting the signature. A code keeps everything in one tab: the authorization parameters never leave the URL you are already on, the session appears in place, and the flow resumes without a redirect.
There is a second, related trap the design avoids. The signed authorization request carries its own short expiry, and a magic link clicked after that window has closed would fail signature validation with an opaque error. Because the code path never leaves the tab, an expired request is caught up front and shown as This link has expired / Your connection request timed out. Please start the connection again from your app.
The Google button appears when Google sign-in is configured for your Leed environment. If your sign-in screen shows only GitHub, or only the email form, that is a configuration difference and not something you can turn on from your account.
Google is a trusted provider in Leed, which has two consequences worth knowing:
- A Google sign-in can create a login as well as resume one.
- It can be linked to a Leed account whose email address is different from the Google one.
GitHub
The GitHub button, when it appears, is sign-in only. GitHub will never create a Leed account: if no Leed account matches, you are refused with GitHub sign-in only works for existing Leed accounts… rather than being signed up.
What it matches against is broader than people expect. Leed looks at every address verified on your GitHub profile, not only your primary one, and finds the Leed account that holds one of them. That is deliberate — the common case is a developer whose GitHub primary is personal and whose Leed login is a work address.
One GitHub account signs in to one Leed login. If GitHub is already connected somewhere else, connecting it here fails until it is disconnected there.
The four methods, side by side
| Method | Where it is offered | Can it create a new account? | Valid for | Notes |
|---|---|---|---|---|
| Magic link | The normal sign-in screen | No — the account must already exist | 5 minutes, one use | Arrives by email; opens in whichever browser you click it in |
| One-time code | Only when an application is connecting | No | 5 minutes | Typed back into the same tab, which is what keeps the connection request intact |
| Both states, when configured for your environment | Yes | n/a | Trusted provider; can link to an existing Leed account on a different address | |
| GitHub | Both states, when configured for your environment | No — sign-in only | n/a | Matches any address verified on your GitHub profile, not just the primary |
Where you land afterwards
An ordinary sign-in drops you on your home tab, which is Know, the dashboard. Touring the Workspace names the rail and the tabs you are looking at.
When you were sent to the sign-in screen from somewhere else, Leed returns you there instead:
- A device link — approving a terminal sends you to sign in and back to the approval screen, with the code you were given still in place. Authorizing Devices and Clients covers that screen.
- An invitation — signing in from an invitation returns you to the invitation so you can accept it, as described in Joining and Switching Workspaces.
- An application’s connection request — you go straight to the authorization screen rather than into the workspace.
Only destinations inside Leed are honored. A return address that points at another site, or that tries to climb out of Leed’s own origin, is discarded and you land on your home tab instead.
If you belong to more than one workspace and Leed cannot tell which one you mean, it sends you to the organization picker first. That is the picker doing its job, not an error.
How long you stay signed in
| Behavior | Value |
|---|---|
| Session length | 7 days |
| Extended after | A day’s gap, the next time you use Leed |
| Sign-out scope | The session you are using — nothing else |
| Where the others are listed | Your profile’s Security tab |
Signing out ends only the session you are signed out of. Another browser, another machine, a phone, the CLI and any connected application all stay signed in until they expire or you revoke them. The full list of where you are signed in, with a revoke control on each row, is on the Security tab — that is the screen to use if you have lost a laptop, and it is also the fastest way to satisfy the recent-sign-in requirement that connecting or disconnecting GitHub imposes.
Signing in from a terminal works differently again: the CLI shows you a code and asks you to approve it in a browser, which is described in Authorizing Devices and Clients and, from the command line’s side, in CLI Authentication.
What Leed does not offer
There is no password sign-in, no password reset, no two-factor code, no authenticator app and no passkey. None of these is coming later on your account settings screen; there is no screen for them, because there is no password to protect in the first place.
If a message on the sign-in screen is stopping you, it is quoted verbatim with its cause and its remedy in Sign-in Troubleshooting. If you have no account at all yet, start at Creating Your Account.