Fine-grained grok_ personal API keys fail My Machines `agent worker` liveness (404 valid:false); `/v1/me` OK

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Cursor CLI — Self-Hosted Machines / My Machines (agent worker)

On a Cursor Team plan with Allow Self-Hosted Machines enabled, fine-grained personal user API keys (grok_…) with both:

  • Agents — Run agents
  • Cursor CLI and SDK — Sign in to the Cursor CLI and SDK

…authenticate for account APIs but cannot start a My Machines worker.

Observed:

Check Result
GET https://api.cursor.com/v1/me with Bearer key HTTP 200 (key name + account)
agent status (browser login, no CURSOR_API_KEY) Logged in
env -u CURSOR_API_KEY agent worker debug Authentication required for worker debug (stored CLI login is not enough for worker)
CURSOR_API_KEY=grok_… agent worker debug Auth Classification: liveness endpoint returned 404: {"valid":false}
agent worker start with same key Failed to validate worker account settings: liveness endpoint returned 404: {"valid":false}

Reproduced with two separately minted fine-grained keys (same two grants) on CLI:

  • 2026.10.01-e373342
  • after agent update → 2026.10.14-941492e

Related thread New permission-based user API keys can't run CLI/SDK agents (Service Unavailable / HTTP 503); older key works was about local CLI/SDK agent runs returning HTTP 503. Colin marked that fixed on 15 Oct 2026. Our failure is a different endpoint/error (worker liveness 404 valid:false) and still reproduces after that fix and after CLI update.

A prior legacy personal key (crsr_…) had successfully run this My Machines worker on the same Mac before we switched to grok_.

Actual Behavior

Worker validation fails with liveness endpoint returned 404: {"valid":false} even though /v1/me succeeds and the key has both documented agent/CLI grants.

Steps to Reproduce

  1. Team account, Self-Hosted / My Machines allowed.
  2. Dashboard → API Keys → create fine-grained personal key with Run agents + Sign in to the Cursor CLI and SDK.
  3. export CURSOR_API_KEY=… (the new grok_ key). Confirm curl -s -H "Authorization: Bearer $CURSOR_API_KEY" https://api.cursor.com/v1/me returns 200.
  4. agent update (we used 2026.10.14-941492e).
  5. From a git workspace: agent worker debug then agent worker start --name "repro-worker".

Expected Behavior

Personal user API keys documented for My Machines should pass worker validation and register a worker (or docs should state which additional grant/key type is required).

Operating System

MacOS

Version Information

  • agent CLI: 2026.10.14-941492e (also failed on 2026.10.01-e373342)
  • Mode: My Machines (agent worker start), not Team Pool / --pool
  • Plan: Cursor Team
  • OS: macOS (Apple Silicon Mac)

Additional Information

  • Dashboard key UI only offers those two grants for this personal key; no separate “My Machines / self-hosted worker” permission is visible.
  • Browser agent login shows logged in via agent status, but worker mode still requires --api-key / CURSOR_API_KEY on this build.
  • We are not trying to use a team Admin / org / service-account key for My Machines.

Blocks Self-Hosted My Machines workers that need a durable API key (LaunchAgent/systemd). IDE/cloud agents otherwise usable.

Please advise whether fine-grained grok_ keys are supposed to support My Machines worker liveness, and if not, what personal key type/grant is supported now that legacy keys are hard to mint.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report and repro. And yes, you’re right that this is separate from the 503 issue.

When the worker starts, it checks its API key through a separate validation step, and that step doesn’t recognize the new keys with the grok_ prefix yet. So /v1/me returns 200, but the worker still sees 404 valid:false, no matter what grants are attached to the key. I’ve passed this on to the team.

Until that’s fixed, you can run the worker with browser login instead of an API key. This login refreshes itself, so it also works for a long-running worker like a LaunchAgent or systemd service.

  1. unset CURSOR_API_KEY and remove it from the LaunchAgent plist too if it’s set there.
  2. Run agent logout, then agent login, and finish the login in the browser.
  3. From the git workspace, run agent worker start --name "repro-worker".

If step 3 still shows Authentication required, send the output of agent status and agent --version, and we’ll take a closer look. I’ll reply here when there’s an update on the main issue.