A seat's credential to its AI provider

⚠ This page is about the other meaning of seat, and the collision is real rather than a wording slip. On the authorization server a seat is one person's account — the thing you invite, list and revoke in How a person signs in. On a machine that runs work, a seat is a named worker identity with its own isolated profile directory on that host. Both are the product's own vocabulary, in two different commands, and this page means the second.

A seat in this second sense holds a credential to the AI provider it runs work through. That credential is not the product's to mint, not the product's to renew, and not something any command can repair. A human being logs that seat in, on that host. Everything below follows from that one fact.

Two credentials live near each other, and they are not the same thing

⇒ Renewing the transport lease does not re-authenticate a seat, and neither does any other maintenance command. If a seat has stopped being able to work, the transport is usually the first thing somebody checks and it is almost never the answer.

The product never mints or forges a provider credential, and it will not substitute a different kind of credential to avoid asking you. The only non-interactive path any of these providers documents is a separate API credential with a different billing class — swapping one silently for the other would change what the seat costs to run, so the product refuses to.

What the product does do is conduct the provider's own interactive login for you, over the connection to that host, so that the login lands where the work will look for it. The human still does the human part: read the address, paste the code. The credential is written by the provider, into that seat's own profile directory, exactly as it would be if you had typed it yourself.

Ask the record before you touch anything

Reading a seat's credential state is free. It performs no probe, starts no work, dials no provider and costs nothing.

⚠ What it reports is what the last piece of work on that seat measured, not what the credential is doing this second. It reads the product's own record; it is not a live question put to the provider. Every reading says so on every invocation, and that sentence is worth reading rather than skipping.

⚠ An absence is reported as an absence. A seat that no work has ever finished on reads as never measured — never as healthy. Read it that way.

The one confusion that costs a day

⛔ A spent usage allowance and a dead credential are different failures with different repairs, and they present almost identically.

Conflating these two once cost a working day. If you take one thing from this page, take the habit of reading which of the two the record says before you decide to repair anything.

⚠ Discovering that a seat is dead costs nothing. A genuinely dead credential is refused at the cheapest possible reading, with no work done and nothing spent. What costs something is distinguishing a stale credential from a logged-out one — that takes one real attempt, and that same attempt is the cure when the answer is stale. What that one attempt costs depends on how the seat is billed: against a shared allowance the scarce thing is the clock, on a metered account it is money from the first token, and on your own hardware it is a named zero and wall time.

Never type the profile path by hand

⛔ The provider keys its stored credential on the profile path as typed, character for character. A trailing separator does not produce an error. It creates a second account and logs into that one.

The seat's real credential is then left to expire with nobody watching, while the seat goes on answering perfectly under the other spelling — and then stops, for a reason nothing on any screen connects to a keystroke from days earlier. This is measured, not theoretical: it took one seat out of service for a full working day.

⇒ So you never type the path. Name the machine, and the seat if that machine carries more than one, and let the product compose the path from the machine's own signed record. If a machine carries several seats the command refuses and names them all rather than guessing, because logging the wrong one in writes a credential nothing will use and leaves the broken seat broken.

Before it touches anything it names the credential entries it found, one line each, and it distinguishes present, absent and nobody looked. ⚠ Nobody looked is never folded into absent. A reading that could not be taken is not a reading that came back empty.

Do not delete a credential entry that merely looks stale

⛔ A credential store is not a list of junk. An entry that looks spare can be the only live credential a seat has — that has happened, on live seats, and the tooling used to print a removal command underneath a warning saying exactly that.

The safe order is not negotiable and it is short:

1. log the seat in, naming the machine rather than a path;
2. read the verification and require a real pass;
3. only then decide about any other entry.

Deleting one is an owner's act, performed with the credential you actually rely on already proven working. Nothing is deleted for you.

What a verification is worth

Only an answer to a real request is a pass.

• an answer means the seat can work;
• a named refusal, or a failure to start, means it cannot;
• nothing at all is not a pass. A probe that did not run, or ran and said nothing, has measured nothing.

⛔ A cheap call that reports success on a dead credential is not a check. One such call answers successfully, with no error and nothing on its error stream, over a credential that has expired — a green over a corpse. A check whose failure is indistinguishable from its success is not a check, which is why verification here costs a real request.

On a machine reached over a remote shell, expect it to happen again

⚠ This one is the product's own defect and every reading of an affected seat says so.

Work dispatched to a machine over a remote shell runs under a confinement whose writable area does not include the seat's own profile directory. The provider's own quiet renewal therefore cannot land, and the credential dies roughly one token lifetime later — on a record that reads perfectly healthy right up until it does.

⇒ The login act repairs it, and the repair is not a cure. It works because your hand runs outside that confinement. ⛔ Do not read a successful repair as evidence that the seat's own credential was the problem. It will come back. This is a named gap and it is listed as one.

What has been measured, and what has not

⚠ The product is explicit about the edge of its own knowledge here, and it is worth knowing which side of that edge you are on.

• The binding is measured for every provider. The profile directory the login writes into is the same one the work reads from, composed by the same code, so a repair and a run cannot end up naming different homes. This is the part that matters most and it holds everywhere.
• How a login is entered is measured for one provider only. For the others the product runs the provider's own command and does not claim to know that this is how that provider prompts. Where it does not know, it says so above the line it hands you rather than guessing on your behalf.

⇒ Read an unmeasured note as nobody has checked this yet, not as this is broken. It is the honest edge of what has been driven end to end, and it is stated so that a success is not read as a measurement.