Cloud Agent Builds: team/environment secrets are not injected into the Build `install` step (runtime works)

Support Bug Reports
1

Summary
On a repository-managed Cloud Agent environment, none of our team/environment secrets reach the Build install step, so every Build fails at install. Runtime injection works fine (interactive agents on the same environment get the secrets) — the failure is isolated to the Build phase. Per the Builds docs, team/environment secrets should be available to install for private package registries.

Environment

  • Name: WebApp Test
  • Environment ID: 95e8736e-9a6f-11f1-ba66-0e7d0216e441
  • Owning team: 17048573
  • Type: repository-managed (.cursor/environment.json with a build.dockerfile)

What works (runtime)
Our interactive Cloud Agent on this environment receives the secrets at runtime:

  • GITLAB_TOKEN is a live env var
  • CLOUD_AGENT_ALL_SECRET_NAMES = GITLAB_REGISTRY_USER,GITLAB_TOKEN,PIP_INDEX_URL
  • Confirmed functionally: at runtime we logged into the private registry, pulled private images, and installed private wheels successfully.

What fails (Build install)
Every Build prints, in the install step:

“unset” = the variable is absent, not empty.

What we tried (all fail identically at install → INSTALL_FAILED)
We set the secrets at both Team and Environment scope and cycled every Type:

  • Environment Variable (Environment scope) — build bld-20260818-abd64058-ec91-4a17-b455-f6c6c02c2620
  • Build Secret (Team + Environment) — build bld-20260817-fcb7567c-5cbb-4c6e-a2b3-70cbff0e44da
  • Runtime Secret (Environment) — build bld-20260817-2421b45a-0a5c-43d1-a9dd-c0b263d9c945

What we ruled out

  • Not misconfigured scope: the same Environment-scoped secrets are received by interactive agents at runtime.
  • Not a network issue: egress is allow-all and public image pulls succeed in the same build.
  • Not empty values: the report prints “unset”, not “defined but empty”.
  • We know Build Secret type is documented as Dockerfile-mount-only; the concern is that Environment Variable / Runtime Secret (team/environment scope) also never reach install.

Related but distinct
This looks related to — but different from — the runtime-injection bug fixed in July (topics 166083 and 165916). Those were about secrets missing in the running VM; runtime works for us now. Ours is specifically the Build install phase. Note the “recreate in Personal scope” workaround from those threads does not apply here, since user secrets are excluded from Builds by design (per the Builds doc).

Logs

[aisap-cloud] credential environment visible to this step:
[aisap-cloud]   GITLAB_TOKEN: unset
[aisap-cloud]   PIP_INDEX_URL: unset
[aisap-cloud]   GITLAB_REGISTRY_USER: unset
[aisap-cloud] No GitLab credential reached this step
[INSTALL] Exit code: 1

build_logs.txt (221.1 KB)

Question
How do we make a team/environment secret available to the Build install step? If this is supposed to work per the docs, it appears to be a bug in secret injection for Builds — please investigate builds abd64058 and fcb7567c.

Secrets
Secrets2268×930 133 KB

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

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!

7

Where does the bug appear (feature/product)?

Cloud Agents & Automations (cursor.com/agents, scheduled/event)

Describe the Bug

Team/environment secrets are not injected into the Build install step for a
repository-managed Cloud Agent environment, so every Build fails at install.
Runtime injection works correctly — interactive Cloud Agents on the same
environment do receive the secrets — but the Build phase does not, which
prevents us from enabling Builds. Per the Builds docs
(Cloud Agent Builds | Cursor Docs “How secrets work with Builds”),
team/environment secrets should be available to install for private package
registries.

Environment:

  • Name: WebApp Test
  • Environment ID: 95e8736e-9a6f-11f1-ba66-0e7d0216e441
  • Owning team: 17048573
  • Type: repository-managed (.cursor/environment.json with build.dockerfile)

Steps to Reproduce

  1. Create a repository-managed environment whose install script needs a private
    registry credential (we read GITLAB_TOKEN / PIP_INDEX_URL as env vars).
  2. Add those secrets as Team- and Environment-scoped. We tried every Type:
    Environment Variable, Runtime Secret, and Build Secret.
  3. Trigger a Build (manual, config-change, or recurring).
  4. Open the Build’s logs and look at the install step’s credential report.

Result: install prints all secrets as “unset” and exits 1:

[aisap-cloud] credential environment visible to this step:
[aisap-cloud]   GITLAB_TOKEN: unset
[aisap-cloud]   PIP_INDEX_URL: unset
[aisap-cloud]   GITLAB_REGISTRY_USER: unset
[aisap-cloud] No GitLab credential reached this step
[INSTALL] Exit code: 1

(“unset” = the variable is absent, not empty.)

Contrast — the SAME secrets ARE present at runtime on an interactive agent in
this environment:

  • GITLAB_TOKEN is a live env var
  • CLOUD_AGENT_ALL_SECRET_NAMES = GITLAB_REGISTRY_USER,GITLAB_TOKEN,PIP_INDEX_URL
  • Confirmed functionally: at runtime we logged into the private registry,
    pulled private images, and installed private wheels successfully.

Failing build IDs (all INSTALL_FAILED, all show the secrets unset):

  • bld-20260818-abd64058-ec91-4a17-b455-f6c6c02c2620 (Environment Variable, Env scope)
  • bld-20260817-fcb7567c-5cbb-4c6e-a2b3-70cbff0e44da (Build Secret, Team + Env)
  • bld-20260817-2421b45a-0a5c-43d1-a9dd-c0b263d9c945 (Runtime Secret, Env scope)

Expected Behavior

Team/environment secrets should be injected as environment variables into the
Build install step (as the Builds documentation states for private package
registries), the same way they are injected into a running agent. install
should see GITLAB_TOKEN set and the Build should succeed.

Screenshots / Screen Recordings

  1. Secrets table showing GITLAB_TOKEN configured at Team + Environment scope.
  2. The Build install log for abd64058 showing “GITLAB_TOKEN: unset”,
    “No GitLab credential reached this step”, “[INSTALL] Exit code: 1”.

Operating System

Linux (the Cloud Agent build/VM is Ubuntu 24.04; this is a server-side
Cloud Agent issue, independent of the local client OS)

Version Information

[fill in] — from Cursor: Menu → About Cursor → Copy
IDE Version:
VSCode Version:
Commit:

(Note: this is a server-side Cloud Agents/Builds issue, so client version is
likely not relevant, but included for completeness.)

For AI issues: which model did you use?
N/A — this is an environment/secrets-injection bug, not model-related.

For AI issues: add Request ID with privacy disabled
N/A

For Background Agent issues, also post the ID:
bc-60522289-6bf0-4bda-b2b8-843fb633b6f3
(the agent used to diagnose this; the key evidence is the build IDs above)

Additional Information

  • This looks related to, but distinct from, the runtime-injection bug fixed in
    July (forum topics 166083 and 165916). Those were about secrets missing in the
    running VM; runtime works for us now. Ours is specifically the Build install
    phase.
  • The “recreate secrets in Personal scope” workaround from those threads does
    NOT apply here: user/Personal secrets are excluded from Builds by design
    (Builds doc: “User secrets are added only when an agent starts. They aren’t
    available during Builds.”).
  • We know Build Secret type is documented as Dockerfile-mount-only; the concern
    is that Environment Variable and Runtime Secret (team/environment scope) also
    never reach install.
  • Ruled out: not a network issue (egress allow-all, public image pulls succeed
    in the same build); not empty values (report says “unset”, not “defined but
    empty”); secrets are correctly attached (interactive agents receive them).

Does this stop you from using Cursor?

No - Cursor works, but with this issue
(Just-in-time environment setup works and interactive agents run fine; only
Builds are blocked, which means every new agent re-runs a ~15-20 min install.)

8

Hi @Matan_Car!

Thanks for the report. I can confirm that it looks like environment-scoped secrets don’t make it into cloud agent builds. I’ll raise that with the team!

That said, team-scoped environment variables/runtime secrets should. I don’t see these in your matrix.

Screenshot 2026-08-18 at 16.51.09
Screenshot 2026-08-18 at 16.51.092180×622 21.4 KB

Could you give those a try?

10

Thanks it works! I changed the team secrets from build secret type to runtime secret and it worked. When should I use build secret type? because I thought it for the build phase

11

Good to hear!

Build Secrets are specifically for secrets required to build a Docker image (the naming is definitely confusing now that we have an unrelated Builds feature). Let me know if, given that description, you think it should be working!

I’ll share feedback around environment-scoped secrets not making it to the install step for builds.

15

Hey @Matan_Car,

Quick update on this one. The underlying issue where Environment-scoped secrets never reached the Build install step has been addressed on our side, and will be rolled out soon if it hasn’t been already!

Thanks again for reporting this to us!