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

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

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.

Thanks for your help!! SUCCESS