According to agent work --help, there is a --auth-token-file parameter that would let me avoid setting the api key in the env, or via cli.
When attempting to use it though, I get an unauthed error. The --api-key and CURSOR_API_KEY env var methods do work, but I would like to be able to use the file if possible.
Hey, this isn’t a bug, it’s just a bit misleading help text. The --auth-token-file flag expects a pre-obtained JWT access token, not an API key. It’s meant for operator-managed setups like Kubernetes, where the access token is mounted as a Secret. The file contents are used directly as the Bearer token with no exchange step, so an API key will fail validation.
For normal use, go with --api-key <key> or the CURSOR_API_KEY env var. Those run through the standard exchange flow and get a real access token.
We should improve the UX here. At minimum we can detect an API key in the file and suggest the right flag. I’ll log this as an improvement on our side. If you specifically need a file-based option for secrets management, tell me your use case so we can prioritize it.
Thanks Dean. I forgot to mention this is in a k8s cluster. The JWT token flow isn’t mentioned on Authentication | Cursor Docs. Is it an enterprise only feature?
On availability: --auth-token-file and the k8s operator-managed setup are part of Self-Hosted Pool Self-Hosted Pool | Cursor Docs, which is an Enterprise feature. The JWT access token that the flag expects is generated and mounted as a Secret specifically within that setup via the k8s operator.
On Pro, the correct way to deploy workers on k8s is to use the CURSOR_API_KEY env var, for example via a Kubernetes Secret plus envFrom or valueFrom.secretKeyRef, or use --api-key. If you’re interested in Self-Hosted Pool under Enterprise, let me know and I can connect you with the right team.