Install & Sign In

Getting a machine ready takes two human steps: run the install one-liner from the dashboard, then sign the device in with a browser. Both are deliberately interactive — an agent never installs or signs in on a human's behalf.

The install one-liner

curl -fsSL https://omnicli.io/install.sh | bash -s -- <INSTALL_TOKEN>

The dashboard mints the token when a definition is built — see Definitions. Alternatively, set OMNI_INSTALL_TOKEN and pipe the script with no argument. The script runs remote code, but it is short and auditable — review it at https://omnicli.io/install.sh first.

What the installer does

  • Downloads the omni-cli binary for the OS and architecture (Linux and macOS, amd64 and arm64) and verifies its SHA-256 checksum before installing.
  • Downloads the definition's context — a signed manifest and snapshot, authorized by the install token — and verifies those checksums too.
  • Installs the binary to ~/.local/bin and caches the context under ~/.local/share/omni/cache.
  • Writes ~/.config/omni/config.json, pointing the CLI at the backend that served the installer. That file is the CLI's only source of the backend URL — there is no --server flag or server env var.

If ~/.local/bin is not on PATH, the installer prints the exact export line to add. It finishes by pointing at the next step: omni-cli account login.

Install tokens

An install token is scoped to a single build of a definition. It expires after a while, and it can be revoked from the dashboard at any time — revoking stops further installs with that token immediately. A failed context download during install means the token expired or was revoked — mint a fresh one-liner from the dashboard.

Windows (PowerShell)

& ([scriptblock]::Create((iwr https://omnicli.io/install.ps1 -UseBasicParsing).Content)) <INSTALL_TOKEN>

Same behavior as the bash script: binary and context downloads with checksum verification, installed to %USERPROFILE%\.local\bin. The installer adds that directory to the user Path — open a new terminal afterwards so the change takes effect.

Sign the device in

omni-cli account login

Then, step by step:

  • The CLI prints a verification URL and a one-line prompt: enter code: XXXXXXXX.
  • A human opens the URL in a browser, signs in to the account, and enters the code to approve the device.
  • The CLI waits for the approval (up to five minutes), then stores a device-bound token locally. The token identifies this machine and can be revoked without touching other devices.

Signing in is human-only: a non-interactive run (an agent, a pipe, CI) exits with code 6 (interactive_required). Re-running account login while already signed in is a no-op — it won't consume another device slot.

The number of active devices is limited; manage and revoke devices from the dashboard's Account page.

Status and signing out

omni-cli account status    # account, email, plan, and devices
omni-cli account logout    # deregister this device and clear local credentials

account logout deregisters the device on the server — freeing its device slot — and clears the local credentials. If the server can't be reached, the local sign-out still happens and the CLI says to remove the device from the web app so it doesn't keep counting against the device limit.

Removing a device from the web app

The Account page (https://omnicli.io/account) lists devices with a Remove action (click once to arm, again to confirm). Removal revokes the device's tokens immediately; that machine has to run omni-cli account login again and registers as a new device.

Pick your platforms, ship your agents

Sign up, choose the actions your workflow needs, and get a copy-paste install one-liner.

Get Started