Platform Logins

Each platform in a definition gets its own credential, entered once by a human and stored locally. Platform credentials are separate from the OmniCLI account: they never leave the machine — the CLI talks to each platform directly.

How login works

omni-cli <platform> login --context work

Login is interactive and human-only (an agent gets exit code 6). Depending on the platform, the CLI prompts in this order:

• Host — only for platforms that need a server URL, and only on the first login (see the table). A re-login reuses the stored host; --host overrides.
• Account email — only for platforms that authenticate with an email + token pair (Grafana Loki asks for a username / tenant ID instead).
• Token — masked input, preceded by a hint that says what kind of token the platform expects and where to create it. A platform that needs more than one secret (Datadog) prompts for each key separately — you never paste combined values.

Before anything is stored, the CLI validates the credential with a live identity call to the platform — a mistyped token or wrong host fails the login instead of failing the first action later. If the context already holds a credential, the CLI asks before overwriting it. Contexts covers work vs personal.

What each platform asks for

For each platform's action catalog, see https://omnicli.io/integrations.

Platform quirks

Jira and Bitbucket

Both authenticate with the Atlassian account email plus an API token (the same token kind works for either). Jira also asks for the site URL, including the API path — e.g. https://yourorg.atlassian.net/rest/api/3.

Datadog

Datadog needs two keys — an API key and an application key. Login asks for each at its own masked prompt and the CLI sends each under its own header. The host is the regional API site, e.g. https://api.datadoghq.com for US1.

PagerDuty

PagerDuty collects the account email plus a REST API key. The email must belong to a real user on the account — it's the actor PagerDuty attributes writes to, and a bogus email passes login but gets writes rejected.

Harness

One API key is all Harness needs — the key itself identifies your account. The host is your Harness cluster URL: the host in the browser URL you use to sign in to Harness, e.g. https://app.harness.io or https://app3.harness.io.

Grafana Loki

For Grafana Cloud Logs, the username / tenant ID prompt takes the numeric tenant/instance ID and the token prompt takes an access policy token. An unauthenticated OSS Loki accepts any placeholder pair.

Snyk

The host is the regional API base for the Snyk account: https://api.snyk.io (US), https://api.eu.snyk.io (EU), or https://api.au.snyk.io (AU). Create the API token in the Snyk account settings.

Clerk

A Clerk secret key belongs to one instance of one application, so the key decides which users the actions reach. Copy it from the Clerk Dashboard under Configure > API Keys: a development instance issues an sk_test_ key and a production instance an sk_live_ key.

status shows the instance the stored key opens together with its environment, for example ins_2abc123def456 (production). Check it before running anything that bans, locks, resets a credential or deletes — on a production instance those reach the people who use your application.

Hosts are remembered

For host-required platforms (Octopus Deploy, Jira, and the rest marked in the table), the host given at the first login is saved with the credential: actions use it automatically, re-logins skip the host prompt, and --host on any command overrides it. status shows the saved host.

Checking and signing out

omni-cli github status                      # per-context state, identity, and host
omni-cli github logout --context work       # or personal|both; no flag targets the only login

status never prints the secret — just whether each context is logged in and as whom. logout removes the stored credential for the targeted context.

Read this page as markdown — the copy your coding agent fetches.