Cloud Agent environment secrets exist but are never injected into the VM

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

I’m hoping someone from the Cursor team can help determine whether this is a bug or if I’ve missed a configuration step.

Repository:
github.com/davidjonrowe/Vale-BOLT-BUILD

Environment:
davidjonrowe/Vale-BUILD

What I’ve verified:

• Environment is Active.
• Environment is attached to the correct repository.
• Runtime secrets have been created.
• Editing a secret shows “Leave blank to keep the current value”, confirming the secret has a stored value.
• Repository and environment are selected before starting a new Cloud Agent.

However, every brand-new Cloud Agent reports that no environment variables exist.

Example prompt:

Print every environment variable whose name starts with VALE_HOSTED.

Then print every environment variable whose name starts with SUPABASE.

Output:

VALE_HOSTED*
(none)

SUPABASE*
(none)

The Environment Setup agent also reports:

“No environment variables starting with VALE_HOSTED_ are set in this environment.”

I’ve recreated agents multiple times, refreshed the environment, verified the secrets exist, and confirmed the environment is Active.

My expectation is that these runtime secrets should automatically be available inside the Cloud Agent VM.

Questions:

  1. Is there a known issue with Cloud Agent environment variable injection?
  2. Is there an additional step required after creating an environment and adding secrets?
  3. Is this expected behavior, or does it indicate a bug?

Any guidance would be greatly appreciated. I’ve spent several hours trying to isolate the issue and have reached the point where everything in the UI appears correct, but the agent never receives the environment variables.

Steps to Reproduce

Steps to Reproduce
Create a new Cloud Agent Environment.
Attach it to a GitHub repository.
Add runtime secrets (for example VALE_HOSTED_SUPABASE_URL, VALE_HOSTED_SUPABASE_ANON_KEY, etc.).
Verify the secrets are stored by editing one and confirming the dialog says “Leave blank to keep the current value.”
Confirm the environment is Active.
Start a brand-new Cloud Agent using that repository and environment.
Run the following prompt:
Print every environment variable whose name starts with VALE_HOSTED.

Then print every environment variable whose name starts with SUPABASE.

Do not do anything else.
Expected Result
The Cloud Agent prints the configured environment variables and their names (or at least detects that they exist).
Actual Result
The Cloud Agent reports:
VALE_HOSTED*
(none)

SUPABASE*
(none)
The Environment Setup agent also reports:
No environment variables starting with VALE_HOSTED_ are set in this environment.
Additional Information
Repository is correctly attached to the environment.
Environment status is Active.
Secrets are present and have stored values.
Tested with multiple brand-new Cloud Agents.
Refreshing the environment and restarting agents does not change the behavior.

Operating System

MacOS

Version Information

Using Cursor Cloud Agents via the web interface (Safari on macOS). I do not have the desktop application installed, so I cannot determine the desktop version.

For AI issues: which model did you use?

GROK 4.5 High Fast

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. Your settings are correct, this isn’t on you. This is a confirmed bug on our side. Secrets added in Environment scope aren’t being injected at runtime for web-launched Cloud Agents right now. That’s why both the agent and the setup agent see nothing, even though everything looks correct in the UI.

A workaround to try: recreate the same secrets in Personal scope, then start a fresh Cloud Agent. Go to Dashboard → Cloud Agents → the secrets section, and select Personal instead of Environment. Personal-scoped secrets use a different injection path and should get picked up.

One note: another user with a similar issue said Personal scope didn’t help either, so I can’t promise it’ll work for you. Please let me know if switching to Personal scope fixes it. That helps us understand how widespread this is.

For the environment-scoped secrets bug, the issue is being tracked, but I can’t share an exact ETA for a fix yet. As soon as there’s an update, I’ll post it in the thread.

7

Thanks for your help!! SUCCESS

8

I can confirm this issue also affects a newly created Desktop-launched Cloud Agent, so it does not appear to be limited to web-launched agents.

Environment configuration:

  • Personal environment
  • Environment-scoped Runtime Secrets
  • Environment is active and attached to the correct private repository
  • Environment was updated at 2026-07-19 12:13 UTC

Fresh reproduction:

  • New agent created at 2026-07-19 12:22 UTC
  • Source: desktop
  • Run: https://cursor.com/agents/bc-2764033a-a639-4ca5-aae0-1047e672613d
  • The run resolved the expected environment:
    • environmentPublicId: cc811b8c-7fe0-11f1-ba66-0e7d0216e441
    • environmentVersionPublicId: cc844166-7fe0-11f1-ba66-0e7d0216e441
  • Setup completed successfully
  • Both configured Runtime Secret environment variables were missing
  • No secret values were printed or exposed

This was also reproduced in an earlier desktop-launched run:

https://cursor.com/agents/bc-38425958-1d81-4f07-9707-025fcfebffd8

This confirms that:

  1. The correct environment is selected.
  2. The run was created after the environment was updated.
  3. Restarting/creating a fresh agent does not resolve it.
  4. The failure also affects desktop-launched agents.

Please attach these bcIds to the existing internal issue for investigation.

9

Thanks for the detailed repro, @koto, and especially for showing that the environment resolves correctly (environmentPublicId is present) but the secrets still don’t get injected. That’s a useful signal. It means this isn’t limited to web-launched agents and can happen even when the right environment is selected. I’ve noted both bcIds and your desktop observation in our internal issue.

While we’re fixing this, try a workaround that worked for the original poster. Recreate the same secrets in Personal scope instead of Environment scope (Dashboard → Cloud Agents → secrets sections, select Personal), then start a fresh agent. Personal-scoped secrets use a different injection path and usually get picked up. I can’t promise it’ll work 100%, but it fixed it for another user. Let me know if it helps on your side.

On the actual bug with environment-scoped secrets, we’re tracking it, but I can’t share an exact fix date yet. Once there’s an update, I’ll post it in the thread.

10

I just wanted to chime in here, I’ve noticed the same, and I’m happy to read it’s acknowledged.

My workaround is to add them globally, but obviously that’s an ugly workaround since we’re adding all secrets globally, which we really do not want to do.

Hoping for a resolution soon, thank you.

12

Hi all!

We deployed a fix last night to fix up secret injection. Can you give it another try?

13

Hello @Colin,

I can verify that I’ve successfully executed an automation with environment scoped variable, the agent was instructed to read and print it out to the run history output.

This test was successful, environment scoped variables now work as far as I can see.

Thank you for fixing this.