The callback is where it breaks
Cursor signs you in by handing off to a browser and receiving the result back. That handoff is the fragile part, and it fails in a specific, recognisable way: the browser tab announces success while the editor sits there as though nothing happened.
When that happens, the network is almost always responsible. Corporate proxies that inspect traffic, VPNs that rewrite local addresses, and firewall rules that block loopback callbacks all produce it. The diagnosis takes under a minute: disconnect from the VPN, or tether to a phone, and try again. If it works, you have a network problem to raise with whoever runs it, not a Cursor problem.
Being on the wrong account
This one is quiet and expensive. Anyone with both a personal Cursor account and a work one can end up with the editor on one and the CLI on the other, and nothing in either interface makes that obvious. What surfaces instead is an unexpected usage limit, or work that does not appear where a teammate expects it.
agent status answers it directly for the CLI. Do that first whenever usage numbers look wrong, before assuming a billing fault.
Headless machines
There is no browser to complete a flow on a CI runner or inside a container, and the intended answer is an API key rather than a workaround.
export CURSOR_API_KEY=...
agent -p "run the test suite and summarise failures"Keep that key in your CI provider's secret store. It authenticates an agent that can write files and execute shell commands, so it warrants the same handling as a deploy token rather than the same handling as a read-only token.
Origin signs in separately
The Origin CLI is a different binary with its own authentication. Running origin auth login also configures a git credential helper, so git push and git pull against Origin remotes work without further setup. Being signed in to agent does nothing for origin, and the reverse is equally true.
Behaviour described against the CLI docs and the dashboard as of 25 September 2026.