For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
Hi @RobertK Thank you very much for raising this. We fixed this briefly but unfortunately it regressed so we have reopened the bug report. I’ve keep you updated on the status of the resolution.
A workarounds that might help in the meantime is to launch into the same environment manually or via the API. A manually started Cloud Agent, or a POST /v1/agents call with env: { type: "cloud", name: "<your environment>" }, gets all the environment’s secrets. This is the most reliable unblock for now.
Hi all, we implemented a partial fix for this last week but kept the work item open because it did not completely resolve the issue. We will keep you updated on the progress and let you know when it is completely patched. Thanks for your patience.
have you tried the workaround? and have you updated your cursor version?
for the workaround :
A workarounds that might help in the meantime is to launch into the same environment manually or via the API. A manually started Cloud Agent, or a POST /v1/agents call with env: { type: "cloud", name: "<your environment>" }, gets all the environment’s secrets. This is the most reliable unblock for now.
Could you elaborate? Do you mean trigger it via a curl webhook?
I asked my Cloud agent about this and give this thread as context, here’s the response: Short answer: there isn't a public "trigger by automation-ID" REST endpoint you can call against b73525ed-…. That UUID is the dashboard/management URL, not a callable trigger. The supported way to start a run via API is to give the automation a Webhook trigger, which generates a private endpoint + key.
Our flow looks like this:
PR changes from draft to open
Cursor Review automation starts via this trigger
If it approves it sets a label to the PR
Smoke test automations triggers via this specific label added
If it approves it reads a few env to push to another repo and make a human approve with a GH PAT. ← This now fails due to env variables missing
Ah darn, I hadn’t noticed but this breaks basically any automations we have for our repo as we use private go modules meaning they need GitHub pat key to do any work with actual compilable code
I had a similar issue of env vars not showing up when running the app or in the terminal using Cursor Cloud. I asked using a prompt but the answer was non-actionable, something about either restarting the VM or creating a new VM. It was an impressively low quality response. After hours of experimentation, I finally stumbled upon the secretive URL. It’s in the form of https://cursor.com/dashboard/cloud-agents/environments/r/github.com/bsalita/elo_ratings where bsalita is my github repo and elo_ratings is the project name. Substitute with your repo and project. On the top-right corner, there’s a drop down menu “Start Setup Agent”. It offers two choices; “Update Existing Env” and “Start Fresh”. Clicking on either will recreate the VM with the environment’s Secrets (the secrets which were entered in the right sidebar of the environment’s page). So there’s two issues. First, when environment variables are changed, a message should appear explaining that the VM must be updated and how to do it. Better yet, a single button should appear which offers to update/start fresh.
Hi All, @here thanks for your patience here, and sorry for the extended disruption.
The fix for this has now landed: automations triggered by GitHub events (pull request changes, pushes, comments, and label updates), as well as CI check and Test Run triggers, will again have your configured secrets and environment variables injected, and setup/update scripts will run as expected. This covers the PR-label-triggered flows several of you described.
Could you re-run your affected automations and confirm secrets are now available in the run? If anything still looks off, please reply with a recent Background Agent ID (bc-...) and a quick note on how the automation is triggered and whether the secret is a personal or team runtime secret. A couple of you mentioned team-shared runtime secrets on git-triggered runs, so I want to make sure that specific case is fully covered for you and will keep watching this thread.
