Sign-in Troubleshooting

Find your message in the tables below. Everything quoted here is quoted exactly as Leed shows it, so the fastest route through this page is to search it for the words on your screen. Nothing on this page requires an administrator to diagnose — but a few of the outcomes do need one to fix, and those rows say so.

If you cannot quote a message — because nothing arrived, or because a screen is simply refusing to move — start from the symptom instead.

flowchart TD
    S{What is actually happening?} --> A["No email ever arrives"]
    S --> B["A red message on the screen"]
    S --> C["I signed in, then Leed bounced me"]
    S --> D["A terminal or an app is stuck"]

    A --> A1["The email never arrives<br/>+ Too many attempts"]
    B --> B1["Sign-in screen · connecting GitHub ·<br/>sending or entering a code · the challenge"]
    C --> C1["You are signed in but Leed<br/>says you cannot be here"]
    D --> D1["Device and app-authorization messages"]

Messages on the sign-in screen

These five arrive as a redirect back to /login after a GitHub round trip, and render in a red panel above the provider buttons.

Messages while connecting or disconnecting GitHub

These come from the Connected Accounts block on your profile’s Security tab, not from the sign-in screen.

Both controls live on the Security tab, which is also where you sign out of a stale session in order to satisfy that requirement.

Failures while sending or entering a code

These six are raised by the browser when a request fails, and each is a single catch-all with no more specific variant behind it — the wording will not narrow down for you.

The email never arrives

Nothing on this list is exotic; work down it in order.

1. Check the address. Both the Check your email and Check Your Email screens print back the address they used. A typo there is the single most common cause.
2. Check spam and quarantine. Sign-in mail comes from a no-reply sender and is exactly the shape a filter distrusts.
3. Do not reuse an old email. Magic links and login codes expire five minutes after they are issued and work once. An email from ten minutes ago is not a spare — request a new one.
4. Wait a moment between requests. Repeated requests from the same place are rate-limited, and the rate limiter’s refusal looks like nothing happening.

One cause worth knowing about because you cannot see it from the sign-in screen: an address that has hard-bounced is suppressed, and further mail to it is not attempted. If mail to your address used to arrive and now never does, that is a case for an administrator or for support rather than for another retry.

“Please verify you are human” never resolves

The challenge on the sign-up and sign-in forms is a Cloudflare Turnstile widget. The Create account and Send magic link buttons stay disabled until it resolves, and if its token expires while you are still typing, the button goes back to disabled and the widget re-arms. Waiting a few seconds for it to settle is usually the whole fix; a privacy extension or a blocked third-party script is the usual cause when it is not.

If the widget resolves but the request is still refused, the response says which half failed:

Three actions are protected by the challenge: creating an account, signing in by email, and requesting a magic link. Nothing else in Leed asks you to prove you are human.

Too many attempts

Repeated sign-in requests from the same place are rate-limited, and a limited request comes back as 429. There is no counter shown and no countdown — wait, then try once more rather than retrying in a loop.

What is never rate-limited is worth knowing, because it tells you where a stuck loop cannot be coming from: reading your session, listing your sessions, signing out, the device-authorization polling your terminal does, and looking up an invitation. All of those are exempt. A loop that will not clear is therefore always on the credential-sending side — magic links, login codes, sign-ups — and waiting is the remedy.

You are signed in but Leed says you cannot be here

These four are not sign-in failures. Your login worked; what failed is placing you in a workspace. The first three need an administrator, and the fourth needs you.

The last one is not an error at all — if Leed sends you to a list of workspaces, that is the organization picker doing its job. It is skipped entirely when you belong to exactly one workspace, which is why most people never see it. It is also deliberately suppressed on the sign-in screen, the picker itself and the app-authorization screen, because each of those manages the choice itself.

The first three are all the same underlying shape: an account that exists on one side of Leed and not the other. An administrator resolves them from Managing Team Members. The most common way to arrive at them is by accepting an invitation that was never finished on the administrator’s side, which is covered from the invitee’s point of view in Joining and Switching Workspaces.

Two more messages come from the picker screen itself: Failed to load organizations. means the list could not be fetched, and Failed to select organization. means the workspace you clicked could not be made active. Both are retryable; if either persists, sign out and back in.

Invitation messages

Device and app-authorization messages

These come from the two approval screens: the device screen a terminal sends you to, and the consent screen an application sends you to. Both are described in Authorizing Devices and Clients.

A code shown in your terminal is approved on the device screen, and the command-line half of the same flow is in CLI Authentication.

When none of these match

Work through this once, in order — it clears most of what is left:

1. Open the Security tab and revoke every session except the one you are using.
2. Sign out.
3. Sign back in with a magic link, in a normal (non-private) window, with extensions disabled.

If it still fails, the three things that make a support ticket answerable on the first reply are: the exact message, copied rather than paraphrased; the time you saw it, with your timezone; and the address you signed in with. If the message came with a code in the URL — ?error=… — include that too.

Errors from the rest of the product — the CLI, the site build, MCP — are collected in Common Error Messages.