cockpit accounts

This reference is generated from the same canonical source distributed as cockpit CLI help. See Cockpit CLI for concepts and safe operating guidance.

Usage:

cockpit accounts [list] [--agent-type <type>]
cockpit accounts create <name> [--agent-type <type>]
cockpit accounts rename <name|id> <new-name> [--agent-type <type>]
cockpit accounts remove <name|id> [--agent-type <type>] --confirm
cockpit accounts login [<name|id|default>] [--agent-type <type>]
cockpit accounts logout <name|id|default> --agent-type antigravity [--confirm]

List, create, rename, remove, sign in to, and sign out of agent account profiles. With no --agent-type, accounts and accounts list return every account for claude, codex, grok, antigravity, cursor, and qoder. Each entry includes its agentType. The default agent type for create, rename, remove, and login remains claude.

cockpit accounts
cockpit accounts list --agent-type claude
cockpit accounts --agent-type claude
cockpit accounts --agent-type codex
cockpit accounts --agent-type grok
cockpit accounts --agent-type antigravity
cockpit accounts --agent-type cursor
cockpit accounts --agent-type qoder
cockpit accounts create work --agent-type codex
cockpit accounts rename work "Work (EU)" --agent-type codex
cockpit accounts login work --agent-type codex
cockpit accounts remove work --agent-type codex --confirm
cockpit accounts logout work --agent-type antigravity
cockpit accounts logout default --agent-type antigravity --confirm

Codex accounts use isolated configuration copies. New accounts do not inherit model_catalog_json, just as they do not inherit provider or connection overrides. When provisioning an existing account, Cockpit removes absolute catalog overrides pointing into the default Codex home from its config.toml, including named TOML profiles. These shared-home references can freeze the model list at an old snapshot. The original configuration is preserved beside it as config.toml.before-model-catalog-migration, without overwriting an earlier backup. The default account's configuration, credentials, relative catalog paths, and catalogs outside the shared home are unchanged. Existing sessions keep their loaded configuration until reconnected; a newly started session uses the migrated configuration.

When listing all types, each entry contains agentType. Every entry also contains profileId (null for the default account), name, emailAddress when available, authState, loggedIn, provider-specific usage, usageState, and usageFetchedAt. A Codex entry's usage.credits is its purchased credit balance, and a Claude entry's usage.limitResetsAvailable and usage.limitResets are its unused limit resets. A Claude entry's usage.extraUsage is this month's extra-usage spend and monthly limit. Each of these has the same shape and omission rules as in cockpit usage. Grok entries also contain authReason, described below. Accounts whose usage state is auth_required or configuration_required remain in the response with those states intact; treat them as unusable. Cursor is the exception for auth_required: its usage is requested with the Cursor CLI's own saved sign-in, but a rejected usage request alone never blocks the account. A Cursor account in that state keeps authState: "ok" while its CLI credential is present and in date, and stays usable; the Usage screen offers to sign in again with the Cursor CLI. A usage reading that simply could not be obtained is reported as unknown — the fetch timed out, the network was down, or the failure could not be classified — and error means the same thing for providers that still report it. Neither is an authentication verdict: such an account keeps authState: "ok" and loggedIn: true when its credential is present, stays usable, and is still chosen by auto selection (ranked below accounts with a known remaining quota).

authState is the authentication verdict for the account: ok (a credential exists and passed the provider's authentication check), expired (a credential exists but no longer works — its stored expiry has passed without a refresh token, or the usage fetch failed because of authentication and the usage state is auth_required), or signed_out (no credential is stored). loggedIn remains for compatibility and is true only when authState is ok, so an expired account is reported as loggedIn: false. The check is lightweight: Claude reads the stored OAuth credential's expiry or the CLI's refresh result, Codex reads the expiry of its stored token and, when the usage API rejects the token, asks the Codex CLI to refresh it before reporting expired, Cursor reads the expiry of its stored token and reports expired when no token can be found for a signed-in identity, never because its usage API rejected the request, Grok reads the expiry and the refresh token of its stored credential (see authReason below), Antigravity reads the token expiry of the profile's OAuth files and treats a rejected token refresh as expired, and Qoder relies on the CLI's logged_in status. A usage fetch that the provider rejected because of authentication (for Grok, a gRPC UNAUTHENTICATED status or an HTTP 401/403) stays expired even while an older cached usage snapshot is still served, and the rejection is remembered across later transient failures until a usage fetch succeeds again. Completing a sign-in from the Accounts settings or cockpit accounts login clears the cached verdict for that agent, so the next cockpit accounts list re-checks immediately instead of waiting for the usage cache to expire. A sign-in completed outside Cockpit (for example claude login in a terminal) is picked up by the next authentication status check in the app: when the CLI reports a signed-in account that Cockpit still remembers as expired, Cockpit re-runs the full check before answering. Auto account selection and the Fleet pre-run account check skip every account whose authState is not ok; sign in again with cockpit accounts login to recover an expired account. An unreadable usage reading never produces that verdict: authState is derived from the credential itself plus an explicit authentication rejection, so a unknown or error usage state leaves authState: "ok" and the account selectable.

Grok access tokens last about six hours and the Grok CLI renews them with the stored refresh token the next time it runs, so an expired Grok access token alone is not a sign-out. One shared decision feeds the accounts list, auto account selection, the Fleet pre-run account check, the Settings sign-in status, the Grok usage reader, and the task start, and each Grok entry reports it as authReason:

The Fleet pre-run account check names the same reason when it rejects a fixed Grok account, for example authentication expired: refresh refused.

create creates an isolated profile and returns it. rename changes only the display name of an existing profile, selected by its current name or its profileId, and returns the renamed account. It never changes the profile id, its stored credentials, or any task's or Autorun's account assignment, and it never requires signing in again. Renaming is allowed while a task or Autorun uses the profile, because those reference the profile by id and only the label changes; the new name appears in the account switcher, Usage, and Settings immediately and after a restart. Fleet YAML is the exception: a node's account: <name> is resolved by name at run time, so after renaming a profile that a fleet targets, update that fleet's account values — otherwise the next cockpit fleet run fails its pre-run account check with account "<old name>" was not found. The default account has no stored profile name, so cockpit accounts rename default ... is rejected with 400. A name is required and is trimmed; a blank or whitespace-only name, a name longer than 40 characters, a name containing control characters, a name already used by another profile of the same agent type, and a name reserved for account selection (default, auto, an existing profile id, or any name starting with profile-, all case-insensitive) are rejected with 400 — the same rules create applies, so profile names stay unambiguous for --account <name> selectors. login opens Settings → Agents in the target Cockpit and starts that provider's existing interactive authentication flow; the command returns after the navigation is sent or queued, not after authentication completes. Omit the account selector to sign in to the default account. remove deletes only named profiles, never the default account, and requires --confirm. Removal is rejected while a task or Autorun uses the profile.

All commands also accept the task transport options --host, --port, and --https to operate another Cockpit. A remote login opens the authentication flow on that remote Cockpit.

Assign a task or Autorun to an account with --account <auto|name|id|default>. Both default to auto, which selects the signed-in account whose longest usage window, such as a weekly limit, leaves the most remaining usage per minute until it resets, and switches accounts after a usage limit. Each Autorun execution resolves Auto again, so recurring runs are not pinned to the account selected for an earlier run. --claude-profile and --codex-profile remain compatibility aliases.

cockpit task run --instruction "Instruction text" --directory /path/to/repo --agent-type grok --account work
cockpit autorun create --name "Daily review" --instruction "Review changes" --directory /path/to/repo --agent-type cursor --account work --type cron --expression "0 9 * * *"

Switch a running task to another account with cockpit task account <id> <name|id|default> (see cockpit help task).

Antigravity account isolation

Antigravity profile sign-in uses a browser-based Google OAuth flow. Cockpit starts Agy with the selected profile's home (HOME, USERPROFILE) and app-data directory (JETSKI_APP_DATA_DIR=<home>/.gemini/antigravity-cli), so installation_id, jetski_state.pbtxt, conversations, logs, cache, and usage history live inside that profile. Developer shell resources and non-credential Antigravity settings (.gemini/settings.json, .gemini/GEMINI.md, .gemini/commands, .gemini/skills) are symlinked from the normal home so tools and existing preferences continue to work; they never carry credentials or quota.

Agy resolves its credential in this order: the JETSKI_OAUTH_TOKEN environment variable, the operating-system keyring item gemini/antigravity, then the token file <home>/.gemini/antigravity-cli/antigravity-oauth-token. A keyring hit always wins over the file, and Agy writes refreshed tokens back to the keyring. On macOS every profile therefore gets its own Keychain, <home>/Library/Keychains/antigravity-profile.keychain-db, which Cockpit puts first in the profile's Keychain search list and makes the profile's default Keychain. Cockpit's sign-in stores the profile token in that Keychain, and a profile that has not signed in yet holds a placeholder there, so Agy never reaches the host user's login Keychain item and never consumes the host login's quota from a profile. Cockpit unlocks the profile Keychain with the password stored next to it (antigravity-profile.password, mode 0600) before every read or write, so the credential stays readable after a reboot locks the Keychain, and it re-seeds the Keychain item from <home>/.gemini/antigravity-cli/antigravity-oauth-token whenever the item is still the placeholder. The placeholder or seed is written only when security positively reports that the item does not exist (exit code 44); on any other failure, such as a timeout or a locked Keychain, Cockpit leaves the item untouched and reports the Keychain as not ready, so a transient error can never replace a stored token. Before a task starts, Cockpit reads the profile's Keychain search list back and refuses to launch the task when the profile Keychain is not first, instead of silently signing in with the shared host login; cockpit accounts login reports a failure when the profile Keychain could not store the credential. The host login Keychain stays in the search list after the profile Keychain so GitHub CLI, Git credential helpers, and other developer tools keep working. On Windows and Linux the keyring is shared by the operating system, so a host login stored there is used by every profile; sign out of it (see below) before relying on profile token files.

Each Antigravity entry of cockpit accounts list includes isolation:

usage.account.source and usage.account.home repeat the quota provenance, and usage.credentialSource / usage.credentialHome repeat the credential provenance, so an exhausted status can always be traced to the auth state and home it was measured for. A profile whose quotaScope is host_login is not an independent quota even when it looks fresh.

logout is the Cockpit equivalent of Agy's /logout. Without --confirm it only reports the exact targets it would clear (targets, each with kind, path, and shared) and changes nothing. With --confirm it clears them and reports cleared and failed. Target kinds:

For the default account the targets are the host item plus the files under ~/.gemini; every other profile, and Agy started from a terminal without a profile, that relied on that host login is signed out too. For a profile the targets are the profile Keychain item and the files under that profile's home only; the host login is never touched. When a profile's effective credential is the shared host login (Windows, Linux, or a macOS profile whose Keychain is not ready or not first in its search list), the report sets sharedCredential to that host item and the message points to cockpit accounts logout default --agent-type antigravity --confirm. Cockpit never runs logout automatically. Manual equivalent: open a terminal with the same HOME, run agy, and enter /logout, then sign in again with cockpit accounts login <account> --agent-type antigravity.

When Cockpit reports an Antigravity quota as exhausted, the usage message names the home and credential source the quota was measured for and points to this recovery procedure.