Cloud Agent Runtime Secrets Not Injected Into HQ Environment

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

A newly started Cursor Cloud Agent is using the correct HQ environment, the correct active build, and the correct Git commit, but none of the Environment Variables or Runtime Secrets configured on that environment are injected into process.env.

The build itself succeeds. npm install, Prisma generation, package builds, and database readiness all pass.

The only remaining failure is runtime environment-variable/secret injection.

The affected agent reports all eight configured variables as missing even though they are saved on the HQ Cloud Agent environment.

Steps to Reproduce

  1. Create/use a Cloud Agent environment connected to repository IFCDC9/IFCDC.

  2. Configure Environment Variables / Runtime Secrets on the environment.

  3. Build the environment successfully.

  4. Confirm the correct build is ACTIVE.

  5. Start a completely new Cloud Agent from that environment.

  6. Confirm the new agent is using:
    Environment: HQ
    Git commit: ba22b65
    Build: bld-20260915-abd61270-eb1b-459c-a910-4ed2c8edd340

  7. Check presence only of the configured environment-variable names in process.env.

  8. All configured names are absent.

The affected new agent is:
bc-2974ec68-94ee-4813-9f73-eb3c6f989216

The missing configured names are:

JWT_SECRET
FOUNDER_SEED_PASSWORD
GRANTS_OPERATOR_PASSWORD
MASTER_OWNER_EMAIL
GRANTS_OPERATOR_EMAIL
PUBLIC_APP_URL
PUBLIC_BASE_URL
AURA_OPENAI_API_KEY

No secret values were printed or exposed.

Expected Behavior

A new Cloud Agent started from the HQ environment should receive the Environment Variables and Runtime Secrets configured for that environment.

The variables should be available to the application through process.env while secret values remain protected/redacted.

The expected result is:

TRIAGE_ENV=PASS
TRIAGE_PRISMA_READY=PASS
TRIAGE_DB_READY=PASS

Operating System

Windows 10/11
Other

Version Information

Cursor Cloud Agent – Web
Environment: HQ
Active Build: bld-20260915-abd61270-eb1b-459c-a910-4ed2c8edd340
Agent: bc-2974ec68-94ee-4813-9f73-eb3c6f989216
Git Commit: ba22b65
Client: Android web browser

For AI issues: which model did you use?

Codex 5.3 Medium

For AI issues: add Request ID with privacy disabled

bc-2974ec68-94ee-4813-9f73-eb3c6f989216

Additional Information

Environment ID:
ba66dc68-ab83-11f1-b532-320a589b8025

Active Build:
bld-20260915-abd61270-eb1b-459c-a910-4ed2c8edd340

Affected Agent:
bc-2974ec68-94ee-4813-9f73-eb3c6f989216

Git Commit:
ba22b65

The active build is successful and the new agent boots from the correct HQ environment and build.

Prisma readiness: PASS
Database readiness: PASS
Runtime environment readiness: FAIL

All eight configured Environment Variables / Runtime Secrets are absent from process.env in the new agent.

No secret values were exposed or changed.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @user, thanks for the detailed report.

The injection itself is working, the issue is where the secrets were saved. Your account has two Cloud Agent environments for the same repository: the one your agents actually launch from, and a second one created later by the environment setup flow. All eight variables were added as environment-scoped secrets in the second environment, so agents starting from the first environment never receive them. Environment-scoped secrets only apply to agents that run in that exact environment.

Because the environment your agents launch from is now configured from the .cursor/environment.json file in your repo, the dashboard doesn’t show a Secrets section for it, which is likely how the values ended up on the other environment. The simplest fix is to save them as personal secrets instead, since those apply to every environment for that repo:

  1. Open the Cloud Agents Secrets page in your dashboard (My Secrets).
  2. Click Add Secrets.
  3. Paste your eight entries in KEY=value form. Use Environment Variable for the non-sensitive ones (such as public URLs and contact email addresses) and Runtime Secret for the rest, so their values stay redacted in agent output.
  4. Under “Apply to”, either leave it set to all repositories or select the specific repository.
  5. Save, then start a brand new Cloud Agent (existing agents won’t pick up newly added secrets).
  6. *6. In that agent, run: test -n "$JWT_SECRET" && echo set (repeat for the other names). Runtime Secret values are redacted, so check presence rather than printing them.

Alternatively, you can start agents from the environment where the secrets already live.