Credentials and access

Understand browser sessions, CLI authorizations, API keys, passkeys, and the local credential store.

UnlimGPT keeps the following access boundaries separate. Review them in Settings for the selected account and organization before removing access from a lost device.

  • Sign-in methods link Google or email/password to the same account.
  • Passkeys are authenticators such as Touch ID or a hardware security key.
  • Browser sessions represent signed-in browsers and devices; each can be revoked.
  • CLI authorizations are OAuth grants with their own scopes, expiry, and refresh-token family.
  • API keys authenticate applications and developer tools; each key has its own lifecycle.

The passkey or second factor proves a sign-in step; it does not substitute for an API key in an HTTP request. A CLI OAuth grant permits the CLI's authorized account operations, while a separate organization API key is used by the configured AI client. The organization bound to the key determines whose plan and credits apply, even if you are signed into a different organization in another browser tab.

Choose the right revocation

If a browser is lost, end its browser session. If a workstation running the CLI is lost, review its CLI authorization and the API keys stored for its clients. The current authorization list shows a generic CLI label and dates, not a reliable device name; if several grants cannot be matched to the lost workstation, revoke all CLI authorizations and sign in again only on trusted devices. If an application key is exposed, revoke that key and issue a replacement. These are separate actions: revoking one API key does not sign out browsers, and ending a browser session does not silently delete an application key. Account security gives a recovery sequence.

Start containment from another trusted device if the original is unavailable. Review the affected client's key name and masked prefix in API keys, revoke the exposed key, issue a replacement and verify it against the free model catalog. Update every workload that used the old key. A browser session or CLI grant still active afterward needs its own review; changing a password does not prove those credentials were revoked.

Store and verify credentials

Local raw API keys and the CLI refresh token live in the operating-system credential store. Configuration files contain only endpoints, model identifiers, profile names and credential-helper commands. A key appears in full once when created; the later API key list shows metadata. Check a replacement key with the free model catalog before a paid call, then confirm the old key is inactive.

For a browser-created key, you choose a trusted destination for the one-time value. For a CLI-created key, confirm the installed CLI version supports the operation; the CLI stores the raw value in the OS credential store and keeps only its ID in the profile. A guided external client may copy the key through the clipboard into its own secret field, so that client's storage also becomes part of your access boundary.

Keep keys, tokens, cookies and request content out of repositories, logs, URLs and support reports. Developer-data privacy lists safe diagnostic fields. The CLI security guide explains local secret delivery and guarded configuration rollback.