Cursor login fails on macOS

If you open a Cursor workspace and see an error like:

✗ Login failed
Failed to store authentication tokens: Security command failed:
Security process exited with code: 195

Authentication required to use Cursor Agent. Please run 'agent login'
to authenticate.

…this is a Cursor limitation on macOS, not a Qorin bug. Here's why it happens and the one-time fix.

Why it happens

Cursor stores its login token in the macOS Keychain. The Keychain is only reachable from a process running inside a logged-in graphical (GUI) session. Qorin runs your CLI agent through a background service, which is not in that session — so Cursor's security call to read or write the Keychain fails with exit code 195.

Claude Code, Codex, Gemini and opencode are unaffected because they store their credentials in a file under your home directory, not the Keychain — opencode keeps its in ~/.local/share/opencode/auth.json, which a service-spawned process reads without any GUI session.

The fix: use a Cursor API key

Cursor's CLI supports headless authentication with an API key, which bypasses the Keychain entirely. This is the recommended setup for running Cursor through Qorin (and works on headless Macs too).

1. Generate an API key

1. Open the Cursor Dashboard → Settings → API Keys.
2. Create a new key and copy it (it looks like ck_...).

2. Save it in Qorin (recommended)

Open Settings → Cursor in the Qorin dashboard, paste the key, and Save. Qorin stores it encrypted and injects it as CURSOR_API_KEY every time you launch a Cursor workspace — on any of your hosts, no shell config needed.

You can also override the key for a single workspace from the field in the New workspace dialog (when you pick Cursor as the CLI). That value is used only for that spawn and isn't saved.

Where the key lives

The saved key is encrypted at rest and only ever leaves the server to be handed to your own agent at spawn time (over the same TLS channel as the rest of the workspace traffic). Remove it any time from Settings → Cursor.

Alternative: your login shell profile

If you'd rather Qorin never hold the key, export it on the host instead — every workspace on that machine picks it up:

zsh — ~/.zprofile

echo 'export CURSOR_API_KEY=ck_your_key_here' >> ~/.zprofile

bash — ~/.bash_profile

echo 'export CURSOR_API_KEY=ck_your_key_here' >> ~/.bash_profile

Use the login profile, not .zshrc / .bashrc

Qorin spawns the CLI through a non-interactive login shell (zsh -lc / bash -lc). It sources login-mode files (.zprofile, .bash_profile) but not the interactive ones (.zshrc, .bashrc). Put the export in the login profile or it won't be picked up.

3. Restart the workspace

Open a Cursor workspace in Qorin and Restart it (3-dot menu → Restart) so it spawns with the new key. Cursor now authenticates with the API key — no agent login, no Keychain, no error.

Verifying

Run qorin-agent doctor on the host — the cursor CLI check should show the binary is found. Then start a Cursor workspace; it should drop straight into the agent without prompting for login.

Notes

• The API key is tied to your Cursor account. Treat it like a password — anyone with the key can use your Cursor quota.
• Revoke or rotate the key any time from the Cursor Dashboard; update ~/.zprofile and restart the workspace to apply the new one.