Automation-launched cloud agents get none of their environment's secrets/env vars; API launches into the same environment get all of them (multi-repo environments)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

TL;DR: On a Team plan, an Automation bound to a saved multi-repo cloud environment runs in that environment (correct repos, machine, network egress) but receives none of the environment’s secrets or environment variables.

User-initiated POST /v1/agents launches into the same named environment receive all of them. Reproduced across two environments, five agents, same day.

A single-repo automation on the same team receives its environment’s secrets correctly — the failure appears specific to automations bound to multi-repo environments.

We haven’t found any workaround for getting credentials into these runs (automations have no
secrets mechanism of their own); we’d happily take one. Team name and automation ID available privately.

Steps to Reproduce

Setup

  • Multi-repo environment “ac + Web” (2 repos), created June 10 ~20:57 UTC via the agent-led setup flow (setup session completed, auto-named “ac +1”, renamed June 11).
    Secrets panel: four distinct names (two Runtime Secrets, two Environment Variables), all Team scope.

  • Automation triggered by GitHub PR comments, team_visible scope, environment selected in the automation’s configuration.

  • The automation owner, the PR commenter who triggers it, and the user whose API key makes the POST /v1/agents calls are all the same account (mine).

  • Second environment “ac-web” (same 2 repos): appeared in the automation’s environment dropdown; I created it by a rename - on accident. No idea why it created a new environment just because of a rename.

Repro

Agent Launch path Environment Time (UTC, Jun 11) Secrets present?
bc-71928908-dcb5-400c-85c1-c120dc3ccc97 API, env by name ac + Toqan Web 06:23 all 4 names listed; both credentials verified SET
bc-96b6d6e0-6044-48c5-a170-d0dee5baeb0d Automation (PR comment) ac + Toqan Web 13:04 both credentials absent
bc-c16aa38b-b417-45ee-8bfe-cb2b17026977 API, env by name ac + Toqan Web 13:43 all 4 names; credentials SET
bc-0dd3a7d0-02f6-49b7-a5ef-8ec175ec1604 Automation (same automation, rebound) ac-toqan-web 14:03 0/4 — see diagnostic
bc-ebcaa32e-0b95-4926-99a9-2c0dbb06874d API, env by name ac-toqan-web 14:09 all 4 names; credentials SET

All API launches used env: {type: "cloud", name: "..."} with no repos field. Each automation agent’s record shows the expected env: {type: "cloud", name: "<environment>"} and both repos checked out.

Apart from the missing secrets, the automation runs were otherwise functional. Trigger payload, working gh against both repos, network egress to our staging domain all green. So, every provisioning step except secret/env-var delivery succeeded, twice.

Diagnostic: injection marker variables entirely unset in automation runs

A follow-up command inside automation agent bc-0dd3a7d0’s sandbox:
CLOUD_AGENT_ALL_SECRET_NAMES and CLOUD_AGENT_INJECTED_SECRET_NAMES are entirely unset (not present-but-empty), and even the plain Environment Variable entries from the environment’s Secrets panel are absent. Only 3 basic CURSOR_* variables exist. On the API-launched agents, both marker variables are present and list all four names.

The guess, which you can verify internally: marker variables being unset rather than empty is consistent with the injection step never executing for automation launches, rather than executing and resolving zero secrets.

We can’t see the launch path, so treat this as a hypothesis. It may share a root cause with
Use Configured Environment for Automations not working 100% - /t/use-configured-environment-for-automations-not-working-100/154420 (a staff member acknowledged that issue in March; the thread auto-closed before a fix was confirmed).

Ruled out

  • Stale environment binding: the secrets were demonstrably resolvable via API launch at 06:23, hours before the automation was bound to this environment (~13:01) and fired (13:04). The rebind to the second environment also happened after the secrets existed… same result.

  • Duplicate secret rows as the cause: both environments’ Secrets panels show duplicate team-scoped rows (one name appears as both Runtime Secret and Environment Variable; one appears twice with the same type. Apparently per-environment “Add” appends new team-global rows instead of updating). Messy, but ruled out as the cause: the non-duplicated rows are equally absent in automation runs.

  • Identity mismatch: same account owns the automation, posts the triggering comment, and makes the API calls; all secrets are Team scope.

  • Multi-repo runs being generally secretless: the API launches into the same multi-repo environments inject fine.

  • One confound we cannot rule out ourselves: a third environment (from the automation’s implicit setup flow) turned out to have an active personal override layer, and the UI gives no indication of which layer an automation run resolves. We don’t know whether the two repro environments have override layers. (That third environment is its own mess: it never appears in the dashboard Environments list, can’t be edited: “This environment cannot be edited because its environment.json is not available”, same as “Can’t install environment.json?” (/t/cant-install-environment-json/162717)… and after a “restore to team snapshot” attempt hung in “updating”, it now errors on load entirely.)

Questions

  1. Is secret/env-var injection expected to work for automation runs bound to multi-repo environments? Is there any workaround until it does (we found no automation-level secrets mechanism)?

  2. Which configuration layer does an automation run resolve? The team environment or the triggering user’s personal override? The UI doesn’t indicate this anywhere.

  3. Happy to share the team name, automation ID, and timestamps privately.

Related observations from the same two days (can file separately if preferred)

  • Environments bound to automations disappear from the dashboard’s Environments list while remaining selectable in the automation’s environment dropdown and launchable by name via the API (the two lists clearly read different backing data).

  • Network-allowlist edits on the explicitly-created environment return 400 on every attempt.

  • Automation-spawned agents don’t appear in GET /v1/agents listings for the owner’s API key (direct GET by agent ID works) — another way the automation launch path diverges from the user path.

Expected Behavior

Renaming an environment should not create a new environment.

Automations should have access to the secrets bound to the environment in which they run.

Really I feel like I hit so many bugs! Don’t feel like hashing out all the expected behavior here. Please read the repro.

Operating System

MacOS

Version Information

cursor.com on 11 june 2026

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hi Brett, thank you very much for the detailed report and diagnostics here. You’ve done a fantastic job already identifying the most reliable workaround: launching via the API (or manually in the UI as a one-off run), which injects all of the environment’s secrets correctly.

We have a bug report tracking this (thought it was fixed briefly but it regressed) and we’ll keep you updated on the status of it. Thank you!

8

hahah thank you for taking it seriously!! you know when you get frustrated sometimes that gets in the way of the substance :sweat_smile: - i’ll relay to the team that launching by the api is the way to go for now

10

Hi, any update about bugfix release? My automation is still failing because of secret unavailability..

11

This feels like the kind of bug where the environment identity is correct, but one layer of context is not being carried through.

If the same named environment works through the API but loses secrets through Automations, I would expect users to assume those two launch paths are equivalent. The dangerous part is that the repo context looks right, so the missing secrets are easy to misdiagnose as an app or CI issue.

12

Not yet! We are aware of it, and we’ll keep you updated!

13

Any update on this? This is very disruptive issue.

14

@Stephen-S-H Not yet, we’ll keep you updated though, thanks for your patience

15

Seems like it started to work again!

16

Still not working correctly for me personally

17

Thx for confirming @Karel_Hynek !

Hi @0xturner, The fix for the original issue reported in this thread is live, but your report suggests there may be another trigger path or remaining edge case we need to trace.

Could you share a recent failing Automation run URL or ID, how it was triggered, whether it uses a single-repo or multi-repo environment, and whether Runtime Secrets, Environment Variables, or both are missing? Please do not post any secret values themselves.

18

Hi — thanks. Concrete failing case:

19

Hi all!

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

20

It’s still not working for me. I have a team environment variable which is available when starting a cloud agent for my multi-repo setup, but that same variable is not available through automation

Automation, not working - bc-8ed39c32-b94e-4647-a9c5-4fcac351799b

Cloud agent, working - bc-a03abca6-b3ee-4a79-aef4-f454e798381a

21

Thanks @Adam_Bailey.

Is the Team Environment Variable set to be accessible for All Repositories, or is it scoped down? I believe you’re working with a no-repo automation (correct me if I’m wrong), and these require that any team secrets or environment variables you want injected be accessible to all repositories.

22

@Colin Thanks for the response. This team env variable is accessible for all repositories - it is not scoped. The automation I’m working on is a multi-repo, not a no-repo

23

@Adam_Bailey I’ve sent you a DM!

24

Hi Colin,

It’s still not working for me either. Automations is not able to access a Team All Repositories Runtime Secret.

Automation: bc-171a0301-bfcc-4447-8161-5e1208b5b192

29

Hey @0xturner and @Adam_Bailey, thanks for your patience!

Your remaining reports turned out to have a different cause than the original issue in this thread: both of your automations have a stored “Skip Install” fast-start option on them, and automation runs with that option don’t get Runtime Secrets or environment variables injected. You never chose it: older templates and the “No environment” option used to set it silently, which is why this was so confusing.

We’ve since removed that option from all templates and defaults, so newly created automations aren’t affected. To fix your existing automations: open the automation, re-select your cloud environment in the Environment section, and save. That clears the stored option and secrets will inject on the next run. Recreating the automation from scratch also works. And if you put any workaround credentials directly into automation prompts in the meantime, remember to remove and rotate them once your secrets are flowing again.