Identity and access
Cmdop’s access model is several deliberately separate credentials, each gating one thing and none substituting for another: a fleet join key admits a machine, relay console access admits a person or client, a connection PIN gates who may drive one computer, and a platform API key buys inference. A credential is honoured only at the door it was issued for.
Cmdop separates the computer that performs work from the clients that present it, and it separates the credentials that gate each of them. Understanding which secret does what is the whole of the access model.
Several credentials, several lifecycles
They are not interchangeable, and reusing one where another is expected does not work.
| Credential | What it gates | Who holds it |
|---|---|---|
| Fleet join key | Whether a machine may join a relay | The machine, stored as its durable credential |
| Relay console access | Whether a person or client may use a relay’s console and its APIs | The human operating that relay |
| Connection PIN | Access to one specific machine, as a second factor after relay authentication | The relay, per machine |
| Platform API key | Inference for CMDOP’s built-in engine | The host it is pasted into |
| Platform account sign-in | The account and billing surfaces in your browser | You, in the browser |
Two rules follow directly:
- Joining is not access. A join key brings a machine onto a roster. It does not authenticate you to a console, and it is not a remote-terminal credential.
- A credential is honoured only at the door it was issued for. A remote terminal attach authenticates against the target machine’s own relay door and, when armed, that machine’s connection PIN. Credentials from your own machine are not accepted there. There is no cross-machine credential reuse for terminal access.
Where each check happens
Access is decided by the relay that owns the resource, not by the client asking. A browser can render a machine it cannot open a terminal on; a machine can be on a roster it cannot be driven through. Visibility and authority are separate.
The connection PIN is worth calling out because it is the layer people miss: it gates who may drive one machine, on top of relay authentication. The permission policy is a different question again — it gates what a driver may do once admitted. See Permissions.
External engines keep their own accounts
Claude Code and Codex sign in with their own accounts on the machine where they run. Cmdop drives the installed CLI and does not collect, store, or manage those credentials.
Related
Common questions
What is the difference between a join key and a connection PIN?
A join key lets a machine join a relay. A connection PIN gates who may drive one specific machine after relay authentication. They protect different doors and cannot substitute for each other.
Does my account role decide what can run on a machine?
No. Account and organization surfaces are separate from machine access. The relay admits clients, the machine can require a connection PIN, and permissions decide what admitted work may do.
Does Cmdop store Claude Code or Codex credentials?
No. Claude Code and Codex keep their own local accounts. Cmdop drives the installed CLI and does not collect, store, or transfer those credentials.
Cmdop