Sooner or later Leed shows you a screen asking you to approve something you started somewhere else — in a terminal, or in an AI client that is not Leed. There are exactly two such screens. They look similar, they both end in a button you press once, and they grant very different things. This page tells them apart.
Which screen am I looking at?
| Device code | Application authorization | |
|---|---|---|
| What asked for it | A program on your own machine | An application, usually an AI client |
| Where you meet it | /auth/device, titled Authorize Device | /oauth2/consent, titled Authorize access |
| What you compare | A code shown in your terminal | The application’s name |
| What it grants | An ordinary sign-in, as you | Access to one workspace, bounded by your role |
| How long it lasts | A session — 7 days | Up to 180 days |
| Where you can end it | The Security tab | Nowhere in Leed today — see below |
- I am approving a device
- I am approving an application
Your terminal printed a code and is now waiting. The screen in front of you should be showing the same code. Compare the two, character for character, and press Authorize only if they match. What you are granting is a sign-in: the terminal will be able to do everything you can do, in the workspace you are in right now. Read Authorizing a device below.
An application — a chat client, an editor, an agent — has asked to work inside Leed on your behalf. The screen names it, names the workspace it will get, and lists what it can and cannot do. Nothing here signs the application in as you in the sense the device screen does; it gets a bounded slice of your access to one workspace. Read Authorizing an application below.
Authorizing a device
Where the code comes from
The Leed CLI and its one-line installer both sign in this way. The tool prints a code such as ABCD-1234 and then either opens the approval page in your browser or gives you the address to open yourself.
Codes are eight characters drawn from an alphabet with the look-alikes removed — there is no 0, O, 1, I or L in a Leed device code — so there is never any ambiguity about what you are reading off the terminal. The screen displays them split by a dash after the fourth character.
sequenceDiagram
participant T as Your terminal
participant L as Leed
participant B as Your browser
T->>L: Ask for a device code
L-->>T: ABCD-1234, and where to approve it
T->>B: Open the approval page
B->>L: Sign in first, if you are not already
B->>L: Authorize this code
L-->>B: Device Authorized
loop Every 5 seconds
T->>L: Has this code been approved yet?
end
L-->>T: A session, scoped to the workspace you were in
The terminal is doing nothing but asking that last question over and over. That is why it sits there apparently frozen: it has no way to know what is happening in your browser until you press the button.
The screen
Authorize Device, then the instruction “Verify the code below matches what’s shown in your terminal, then click Authorize.”, a large Verification Code field, and the Authorize button. If the tool opened the page for you, the code is already filled in; if you are typing it, the field inserts the dash for you and ignores anything that is not a letter or a digit.
If you are not signed in, Leed sends you to the sign-in screen first and brings you straight back here with the code intact, so nothing is lost.
Checking the code
After you approve
The screen becomes Device Authorized, with “You can close this window and return to your terminal.” The terminal, which has been asking every five seconds, picks up its session within a few seconds of that.
A code is good for five minutes from the moment the tool requested it, and for a single use. If you take longer, the terminal reports that the code expired; run the sign-in command again for a fresh one.
Which workspace the terminal ends up in
The session the terminal receives is bound to the workspace you were in when you approved it — not to a workspace it chooses, and not to a prompt it will show you later. If you belong to more than one and you meant a different one, switch first and then approve. Joining and Switching Workspaces explains what that choice scopes.
What the device session can do
Everything you can do. It is an ordinary session with your role, it lasts as long as any other session, and it appears on your Security tab badged CLI or Installer with the tool’s version. That row is where you end it — see Sessions, Connected Accounts and API Tokens.
The terminal that printed the code is the Leed CLI, which stores what it receives on your machine; the one-line installer runs this same flow for you the first time, in Installing the Leed CLI.
Authorizing an application
The screen
The screen leads with the application’s own name and logo — “{application} wants to connect to your Leed workspace.” — and never with a raw client identifier. Beneath it, “Signed in as {your address}” confirms which Leed account is about to grant the access, which is worth reading if you hold more than one.
If you belong to more than one workspace, a Workspace to authorize picker appears. With a single workspace there is no choice to make and the screen simply names it.
It acts with your permissions
The screen says it in one line:
Acts with your \ permissions — it can only do what your role allows.
An application never gets more access than the person who authorized it. A Content Writer’s connected client can do what a Content Writer can do, and nothing beyond it. If you want a client to have a narrower reach, the lever is the role of the account that authorizes it — see Roles and Permissions.
It can, and it cannot
The screen prints two lists.
It can:
- Pages & content — read, and create or edit drafts
- Forms & responses — read
- Analytics — read
- Menus — edit drafts
It cannot:
- Publish or delete content
- Access billing
- Manage users or permissions
| Area | Allowed | Never allowed |
|---|---|---|
| Pages and content | Read; create and edit drafts | Publishing; deleting |
| Menus | Edit drafts | Publishing a menu |
| Forms and responses | Read | Anything that changes them |
| Analytics | Read | — |
| Billing | — | Any access at all |
| Users and permissions | — | Any change to either |
This summary understates the real surface
Those four lines are a summary by category, not an inventory. A connected client reaches considerably more than four things: tools across pages, page types, labels, menus and site structure, forms and their responses, contacts and accounts, campaigns and personas, and analytics. Every one of them is still bounded by your role and by the four prohibitions above — the ceiling in that list is real — but “Pages & content — read, and create or edit drafts” is one line standing in for a lot of surface area.
If you want to know what you are actually granting before you press Allow access, the honest answer is on What the Operator MCP Can and Cannot Do, and every tool by name is on the tool index. Setting the connection up from the client’s side is Connecting to the Operator MCP.
One workspace per connection
The workspace you pick is bound to the connection at the moment you approve it. The application does not get a workspace switcher and cannot reach across to another one. To give the same client access to a second workspace, start the connection again from the client and authorize it for that workspace too.
How long it lasts
The screen closes with “This connection will stay authorized for up to 180 days, or until you revoke it.” After that the application has to ask again, and you get this screen a second time.
Denying
Deny records the refusal and returns the application empty-handed. Nothing is granted, no workspace is bound, and there is nothing to clean up afterwards. If you did not start this connection, Deny is the correct button.
Revoking a connection
The practical consequence is that the decision is worth making carefully at the point of approval rather than assuming you can walk it back: check the application’s name, check the workspace in the picker, and deny anything you did not start.
If the screen says the link expired
An authorization request is signed for a short window. Come back to it too late — or reload it after it has been used — and the sign-in screen shows This link has expired, with “Your connection request timed out. Please start the connection again from your app to continue.”
Nothing is wrong with your account and there is nothing to repair. Go back to the application and start the connection again; you will get a fresh request and a fresh screen. Every other message either of these two screens can produce, including “Failed to authorize device. Check the code and try again.” and the two consent-screen failures, is quoted with its cause in Sign-in Troubleshooting. When a client keeps failing after you have approved it, the cause is usually below this layer — MCP Troubleshooting covers those.