# Fine-grained grok\_ personal API keys fail My Machines \`agent worker\` liveness (404 valid:false); \`/v1/me\` OK **URL:** \ **Category:** Bug Reports\ **Tags:** cli, self-hosted, login\ **Created:** [October 16, 2026, 4:40am UTC](https://forum.cursor.com/t/fine-grained-grok-personal-api-keys-fail-my-machines-agent-worker-liveness-404-valid-false-v1-me-ok/174985 "2026-10-16T04:40:13Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [October 16, 2026, 6:19am UTC](https://forum.cursor.com/t/fine-grained-grok-personal-api-keys-fail-my-machines-agent-worker-liveness-404-valid-false-v1-me-ok/174985/5 "2026-10-16T06:19:01Z")
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. --- _[View the full topic](https://forum.cursor.com/t/fine-grained-grok-personal-api-keys-fail-my-machines-agent-worker-liveness-404-valid-false-v1-me-ok/174985)._