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