I’ve tried to run the Cursor CLI on the macOS VM that is used as a Jenkins executor, and I’ve run into a weird issue: agent installs without problems, I can run commands like agent --version and their return the output, but if I try to run agent -p <prompt> or just agent, CLI just quits, outputs nothing and I see that the exit code is 1.
This happens when I try to use agent in a Jenkins job, and it happens when I connect to the VM through SSH and try to use agent manually.
What’s weird is that if I connect to the VM through VNC and launch Terminal.app in a GUI environment, then the agent works.
I though this is the GUI layer issue, as launchctl managername returns Background for SSH, but I tested that on a normal MBP, and agent works through SSH on it.
Any idea how to fix this OR how to debug it further to give you guys more information?
The difference between the GUI terminal and SSH on a macOS VM is most likely due to how auth credentials are stored. On macOS, agent login usually saves tokens in Keychain, which requires the graphical security agent. That isn’t available in SSH or background sessions on a VM, unlike a regular Mac with an always-on GUI user session.
A couple things to try:
Use API key auth instead of browser login. This fully bypasses Keychain. Generate a key in your Cursor dashboard (Integrations > User API Keys), then run:
I can see the key in the env when I do echo $CURSOR_API_KEY, but agent status returns: Not logged in
BUT it also returns Not logged in when I launch the agent in the GUI environment, but it is definitely authorized and works, cause I can run prompts with for example GPT-5.3 Codex. I haven’t logged in via a web browser there, this is a fresh VM on every start, and I do the fresh install of the Cursor CLI there every time.