Cursor CLI for review github PR

[Tran_Quoc_Bao_Storm]

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Currently, we use cursor CLI enterprise to review our PRs. But recently, we got “Please check you have the right key, create a new one, or authenticate without it.”. I tried regenerate new API, but still got it. Beside that i tried authen this key by cursor-agent on my local machine, it still be a valid key. Note that we don’t have any changes in recently workflow github

Steps to Reproduce

•       cursor-agent --api-key "$CURSOR_API_KEY" --force --model "$MODEL" --output-format=text --print "You are operating in a GitHub Actions runner performing automated code review. The gh CLI is available and authenticated via GH_TOKEN. You may comment on pull requests.
  

Operating System

Linux

Version Information

cursor-agent CLI 2026.01.28-fd13201

For AI issues: which model did you use?

composer-1

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the report.

There’s a known issue with CLI authentication in CI environments, especially related to TLS or connectivity between GitHub runners and our API.

Can you share a bit more info to help us debug?

1. The full error text from your GitHub Actions logs
2. How are you passing the API key, via the CURSOR_API_KEY environment variable or the --api-key flag?
3. The relevant part of your workflow YAML (feel free to redact the key)

Also, a quick test: can you try running cursor-agent status in the workflow before the main command? This will confirm whether it’s failing at authentication, or if the issue is further down the chain.

The team is aware of connectivity issues in GitHub Actions. Your report helps us prioritize, especially given the scale of your deployment.

[Tran_Quoc_Bao_Storm]

Tks for your supports @deanrie
I want give some additional information

1. Full Response from cursor-agent

⚠ Warning: The provided API key is invalid.
Please check you have the right key, create a new one, or authenticate without it.

2. cursor-agent status

   ✓ Login successful!
    Logged in (unable to fetch user details)
   

3. I load key by secrets variable of github setting (key still be loaded successfully during workflow)

4. Full command use CLI
   cursor-agent --api-key "$CURSOR_API_KEY" --force --model "$MODEL" --output-format=text --print "You are operating in a GitHub Actions runner performing automated code review. The gh CLI is available and authenticated via GH_TOKEN. You may comment on pull requests.

5. We got this problem from about last week ago, not today

[deanrie]

Thanks for the extra info.

Interesting detail: cursor-agent status shows “Login successful!” but also “unable to fetch user details”. That points to a partial connectivity issue, not a fully invalid key.

There’s a known issue with the TLS handshake between GitHub runners and our API (api2.cursor.sh). This looks like your case. The key is valid (works locally), but the CI run fails.

A couple questions:

• Which runner are you using, GitHub-hosted or self-hosted?
• Can you add this to your workflow before the main command?

  curl -v https://api2.cursor.sh/health 2>&1 | head -30
  

  This will show if there are TLS handshake problems.

I’ve passed this info to the team.

[Tran_Quoc_Bao_Storm]

1. I’m using self-hosted

2. TLS testing logs

   curl: (60) SSL certificate problem: self-signed certificate in certificate chain
   More details here: https://curl.se/docs/sslcerts.html
   curl failed to verify the legitimacy of the server and therefore could not
   establish a secure connection to it. To learn more about this situation and
   how to fix it, please visit the web page mentioned above
   

[deanrie]

Great, I can see the root cause now.

SSL certificate problem: self-signed certificate in certificate chain

This isn’t an API key issue. Your self-hosted runner is going through a corporate proxy with SSL inspection, which injects its own certificate. Cursor CLI can’t verify the connection to api2.cursor.sh because it’s not seeing our certificate, it’s seeing your corporate CA.

Fix: add your corporate CA certificate to the runner’s trust store:

1. Get the corporate CA certificate from your IT/security team.
2. Add it to the runner’s environment variables:

   export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.crt
   

   Or install it system-wide in /etc/ssl/certs/ (depends on your Linux distro).
3. Re-test with curl:

   curl -v https://api2.cursor.sh/health
   

That explains why it works locally (no proxy) but fails on the runner.

Let me know if your IT team can’t provide the cert, there are alternative approaches.

[Tran_Quoc_Bao_Storm]

Tks @deanrie for your supports, i will work with IT department and response for you asap!