Skip to content

feat(admin): connect the Cursor worker without an API key (cursor-agent login) - #265

Merged
bobdivx merged 1 commit into
mainfrom
fix/cursor-worker-login
Oct 21, 2026
Merged

bobdivx merged 1 commit into
mainfrom
fix/cursor-worker-login

Conversation

@bobdivx

@bobdivx bobdivx commented Oct 21, 2026

Copy link
Copy Markdown
Owner

Problem

On prod 2.0.261 the NAS worker (cursor-agent 2026.10.19-6bbf2c4) rejects Mathieu's new Cursor key: "The provided API key is invalid". Cursor's dashboard now issues permission-based user keys with the grok_ prefix. These keys authenticate for /v1/me and local CLI runs, but the self-hosted worker's key validation does not recognise them yet: liveness endpoint returned 404: {"valid":false}. This is a known Cursor bug, acknowledged by Cursor staff on the forum on Oct 16, 2026 and still open. Updating the CLI does not help: 2026.10.19 is the current version.

Cursor's recommended workaround is the CLI browser login. cursor-agent worker --help confirms My Machines workers can "Sign in with agent login, a personal user API key, or a user-scoped token".

Change

  • POST /api/v1/cursor-worker/login installs the CLI if missing, then starts cursor-agent login with NO_OPEN_BROWSER=1 in DevForge's managed HOME and returns the https://cursor.com/loginDeepControl?... URL. It also clears the stored (refused) key. GET /api/v1/cursor-worker/login reports pending / logged_in (from cursor-agent status).
  • The worker starts with the stored API key if there is one, otherwise with the login session: CURSOR_API_KEY is removed from the environment and the session lives in the persistent managed HOME. Install no longer requires a key when logged in (leader only).
  • Status adds logged_in, auth (key / login / none) and key_unsupported (stored grok_ key).
  • UI: the install modal gets a « Se connecter avec Cursor » box. It opens the Cursor login link, polls until it is validated, then installs with no key. grok_ keys get a non-blocking warning; they are not rejected, in case Cursor fixes the bug.
  • The cursor-agent binary is preferred over agent (known name collision).

Tests

  • Rust: login URL / status parsing, grok_ flag, is_logged_in with a fake CLI.
  • Web: installNeeds / workerSummary with logged_in, cursorKeyWarning.

…nt login)

New Cursor user API keys (grok_…) are not yet accepted by the self-hosted
worker's key validation (known Cursor bug: liveness 404 valid:false), and
the CLI reports "The provided API key is invalid". Cursor's documented
workaround is the CLI's browser login, which the worker supports for My
Machines ("Sign in with agent login, a personal user API key, or a
user-scoped token").

- POST /api/v1/cursor-worker/login: installs the CLI if needed, runs
  `cursor-agent login` with NO_OPEN_BROWSER in the managed HOME and
  returns the cursor.com login URL; clears the stored (refused) key.
  GET /api/v1/cursor-worker/login: pending / logged_in.
- Worker start: API key if one is stored, otherwise the login session
  (CURSOR_API_KEY removed from the environment, managed HOME). Install no
  longer requires a key when logged in (this server only).
- Status: logged_in, auth (key/login/none), key_unsupported (grok_ key).
- UI: « Se connecter avec Cursor » in the install modal: opens the
  Cursor login link, polls until validated, then installs without a key.
  grok_ keys get a non-blocking warning pointing to the login.
- Prefer the `cursor-agent` binary over `agent` (name collision).
@bobdivx
bobdivx merged commit 5452a5e into main Oct 21, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant