A developer is setting up the Cursor CLI on their own laptop for everyday interactive work, and would rather not leave a long-lived secret sitting in a shell profile. Which authentication approach matches what Cursor recommends for that situation?

The principle — The Cursor CLI supports two authentication methods, and they are aimed at different situations. Browser-based login is the recommended path for a person working at their own machine, while API keys exist for automation, scripts and CI environments where no browser and no human are available.

Why the key is correct — Running the login command opens your default browser, asks you to authenticate with your Cursor account, and then stores the resulting credentials locally. Nothing has to be pasted into a shell profile, and no long-lived secret sits in a dotfile surviving every future session. API keys remain available, supplied through an environment variable or a command line flag, but they are the automation route rather than the everyday one.

Why the others are wrong — A terminal can start an interactive login: the CLI opens a browser and waits for the flow to finish, so an API key is one of two options rather than the sole one. The CLI does not collect a Cursor email and password at the prompt itself, because the credential exchange happens in the browser. And signing in to the editor does not authenticate the CLI, which keeps its own stored credentials and has its own login and status commands.

Remember this — Browser login for your laptop, API key for machines. If a browser cannot open, print the login URL rather than reaching for a key by reflex.

Sources — Cursor's CLI Authentication documentation.