Every machine you sign in from with codecharter login gets its own entry in
the portal. The list lives in the Authorized devices section on
/api-keys, directly below your API keys. This is where you check
which machines can still renew a license for your account, and where you cut one
off.
How a machine gets onto this list in the first place is described under Browser sign-in.
What the list shows
| Column | Meaning |
|---|---|
| Device | How the machine identified itself when you approved it |
| Created | The day you approved the sign-in |
| Last used | When the device last renewed a license, or "Never used" |
| Status | Active or Revoked |
The CLI identifies itself as CodeCharter CLI on <machine name>, so entries are
usually recognizable straight away. If they are not, rename them, see below.
The list itself shows no token and no prefix. Unlike an API key, whose first twelve characters are listed so you can match a stored secret to its entry, a device token is never displayed again in full after the machine received it, and you never need to copy it anywhere. The confirmation dialog does show a short prefix when you revoke, purely so you can tell two similarly named entries apart.
If you have not signed in from any machine yet, the section says so and points
you at codecharter login.
What a device can do
A device entry can renew a short-lived license for your account, and that is all. It cannot read or change your rules and profiles, and every other portal endpoint rejects it. So the question this list answers is narrow and easy to reason about: which machines can currently keep themselves licensed as you.
Renaming a device
Click the pencil icon next to the name, type a new one, and save. Up to 120 characters, freely chosen.
This is worth doing as soon as you have more than two entries. The default name
is the machine's own hostname, which is fine on a laptop you named yourself and
useless on a container or a freshly imaged workstation. Names like
work-laptop or home-desktop make the eventual "which of these do I still
need" much quicker.
Revoking a device
Click Revoke next to the entry and confirm in the dialog. Do this whenever a machine leaves your hands, for example a laptop you returned, a workstation you reimaged, or a device you no longer recognize.
After revoking:
- The device can no longer renew. Its next renewal attempt is rejected with 401 Unauthorized.
- The license it already holds keeps working until it expires. Licenses are short-lived, so this is at most 24 hours.
- The entry stays in the list with a Revoked badge, so the history remains visible. It has no action buttons any more.
In other words, revocation is not instant lockout, it is a hard stop on renewal. If you need the machine to lose access immediately rather than within a day, you also have to remove the cached license from that machine.
There is no way to un-revoke. If you revoked the wrong entry, run
codecharter login on that machine again; you get a fresh entry.
Revoking versus signing out
These two look similar and are not the same thing:
| Action | Where | Effect |
|---|---|---|
codecharter logout |
On the machine | Deletes the local token. The portal entry stays valid. |
| Revoke | In the portal | Disables the entry for everyone. The local file may still be there. |
Signing out is housekeeping on a machine you still control. Revoking is the security action, and it is the one that works when you no longer have access to the machine at all. On a machine you are handing over, do both.
Devices and API keys
Both live on the same page and both authenticate the CLI, but they are separate lists for separate purposes:
- Devices are developer machines you signed in from with a browser. They can only renew a license and are revoked one machine at a time.
- API keys are secrets for CI and automation. They carry
read:rulesand optionallywrite:rules, and are shared by every job in a pipeline.
Which one to use where is covered under Credentials and precedence.
Audit
Four moments are recorded in your audit log: approving a sign-in, rejecting one, the device collecting its token afterwards, and revoking a device. The approval and rejection entries are the detailed ones: they are identified by the sign-in code and record the device name and the address the sign-in was requested from. The other two are recorded against the device name, and the revocation appears as an API key revocation. If an entry appears that you do not recognize, this is where you check when it happened, see Reading the audit log.
A device that shows "Never used" long after it was created is worth a second look, as is a "Last used" that does not match how you actually work. Revoking is cheap and non-destructive, so if in doubt, revoke and sign in again.