Cursor Origin CLI Reference: Every origin Command, Explained

The Origin CLI is Cursor's command-line client for its Origin code hosting: sign-in and git credentials, repositories, pull requests, rulesets, SSH keys and a raw API escape hatch, all under one origin command. Install it with the script Cursor publishes, then sign in once through the browser.

curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin auth login

Two things the docs say up front that are worth repeating, because both are easy to get wrong on day one. First, origin is not the Cursor Agent CLI; that one is a different binary called agent and lives under its own docs section. Second, the CLI is in early beta along with the rest of Origin, and the docs ask for feedback at hi@cursor.com rather than promising the surface is final.

If origin is not found after the install script runs, the binary landed in ~/.local/bin and that directory is not on your PATH. The fix the docs give is the usual one for zsh: add an export line to ~/.zshrc and source it. Everything in this reference assumes that step is done, and that origin --help prints a command list.

Nine groups, and the reference page lists them in a single table with a one-line usage example each. The shape will feel familiar if you use gh: a noun, then a verb, with a repository inferred from the checkout you are standing in. Four global options work with any command: --auth-token (or the CURSOR_AUTH_TOKEN variable), --endpoint (default https://origin.cursor.com), --version and --help.

Most commands infer the repository from the origin git remote in your current checkout. Override it with -R or --repo in org/name format, so origin pr list -R acme/checkout works from anywhere. That default is convenient and it is also the one to remember when a command seems to act on the wrong repo: check which remote is called origin in the directory you ran it from.

auth manages your session and the git credential helper, and the helper is the part most people actually want from it. origin auth login signs you in through the browser and configures git, so push and pull against Origin remotes need nothing further. The other three subcommands exist for the cases where that default does not fit.

repo covers the lifecycle of a repository from the terminal. Pass org/name to target one; origin repo create <name> without a slash creates it in your account's namespace, which is probably the right default for a personal experiment and the wrong one for anything a team will share. The create-mirrored subcommand is the CLI face of the Sync from GitHub button, and it takes a --github-enterprise-id for GitHub Enterprise Server that you omit when mirroring from github.com.

Rulesets and SSH keys are read-mostly from the CLI. origin ruleset list and origin ruleset view <id> show the merge-time and push-time rulesets configured for a repository, which is how you check from a terminal what the Rules and Protections tab enforces. origin ssh-key add, list and delete manage the public keys on your account; add takes a key file path and -t names the key.

origin pr has its own reference page and sixteen subcommands, and the targeting rule is the thing to learn first. Most of them take an optional target: a number selects that pull request, anything else is read as a branch name, and omitting it uses the open or draft pull request for your current branch. So origin pr view on a feature branch just works.

A few defaults change how you will use it. origin pr create makes a draft unless you pass --status open, and -f or --fill takes the title and body from your commits. --push pushes the head branch without prompting when it is not on the remote yet. On the reading side, --diff, --checks and --comments shape the plain-text output of origin pr view only; for JSON you ask for fields by name, such as files, mergeability, ciState, comments or threads, and filter them with -q and a jq expression.

origin pr create -t "Fix CI" --push --status open
origin pr checks --watch
origin pr review --approve -b "Checked the retry path"
origin pr merge --auto

merge --auto merges once the requirements are met and then returns, and --disable-auto switches that off again for one pull request. The refresh command is the one I initially misread. Pushing to the head branch snapshots a new version on its own; origin pr refresh exists for the case where view or checks still report the previous head commit, and it does nothing when the resolved commits already match the latest version. You should rarely need it.

Review threads are first-class. Every review comment belongs to a thread with its own resolution state, and origin pr thread list, resolve, reopen and reply manage them by id. The docs offer the one-liner a merge gate wants: origin pr thread list --unresolved --json id --jq length, which prints the number of open threads. Note the distinction the reference draws between review and comment: origin pr review files a formal review, origin pr comment adds a discussion comment, and origin pr view --comments lists both.

Five environment variables cover non-interactive use, and they map onto flags you have already seen. Set CURSOR_API_KEY and origin auth login skips the browser. Set ORIGIN_REPO and origin api has a repository to expand placeholders from when there is no origin remote. NO_COLOR does what it says.

origin api is the escape hatch for anything without a first-class command. It makes an authenticated request to the Origin REST API at api.cursor.com/v1/origin and supports request flags similar to gh api: -X for the method, -H for headers, -F and -f for fields, --input for a body file and -q for jq. The {owner}, {repo} and {branch} placeholders in the path expand from -R, from ORIGIN_REPO, or from the origin git remote, in that order of explicitness.

Updates come from the stable channel by default. origin update moves you to the current release on your channel, origin config set-channel switches between latest and stable, and origin config get-channel tells you which you are on. For a tool this new I would stay on stable unless a specific fix is on latest, though the docs do not advise either way. Shell completion is one line, origin completion appended to your shell config, and once it is in place branch-valued flags such as --head and --base complete local branch names.