Protect CLI credentials

The CLI's rotating OAuth refresh token and raw API keys live in the operating-system credential store. Configuration files contain endpoints, model IDs and helper commands, not the key. The CLI does not accept a secret through an argv --api-key flag or offer a plaintext fallback when secure storage fails. The configured AI client still receives a credential through its supported helper or process environment and must be trusted to handle it.

Before using these commands, check that they appear in your installed CLI's help.

Check what is stored where

Use local CLI help to confirm the installed version, then review the non-secret client configuration generated by configure. Do not copy credential-helper output into a terminal transcript or issue report: its purpose is to deliver a key to the selected client. Check the operating-system account's access controls before sharing a workstation. A browser session, CLI authorization and API key each have a separate lifetime and revocation action.

The CLI profile records which key ID and model to use, while the raw value stays in the system store. A configuration receipt records the CLI-owned file edit for guarded rollback; retain it without uploading the surrounding client file. Guided clients can receive a key via clipboard or their native secret field, so verify the client's own storage policy before pasting. A process environment used for secure launch exists for that child process and must not be dumped into logs.

Review and recover

Use Settings → Account & security to review sign-in methods, browser sessions, CLI authorizations and API keys separately. If a workstation is lost, revoke its CLI grant and dedicated API keys from another trusted device. Revoking a browser session alone does not revoke an application key. If the workstation also had a signed-in browser, revoke that session as its own step.

For a device you still control, first list the dedicated keys and identify the clients that use them. Replace a still-needed key, verify access with GET /v1/models, update every client, then revoke the old key. For a lost device or a secret already exposed, revoke the affected key promptly from a trusted browser and restore clients with a fresh value. Do not wait for the device to come online.

unlimgpt keys list
unlimgpt logout

List keys before signing out: keys list requires an active CLI authorization. On a device you still control, logout revokes that authorization and removes its local token; it does not silently revoke API keys. After logout, CLI key-management commands require a new unlimgpt login; if the device is lost, use only a trusted browser. Revoke a specific unused key with the key guide or in API keys. Confirm the old key is inactive and test a replacement with the free model catalog. Keep config receipts for guarded revert; a revert will not overwrite later edits.

If doctor is needed for a failed setup, review its output before sharing it. It is designed to omit credentials and internal execution details, but local paths may still be sensitive to you. Share the CLI version, affected client name and safe failure summary instead of full environment variables or key material. See account security and developer-data privacy.

Next: account security.