Cloud Agent Secrets: updated and deleted secrets keep injecting stale values into new agents

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Secret values in Cloud Agent Secrets appear to be cached per secret name and never invalidated. Once a name has a value, editing it or deleting the row entirely has no effect on newly launched cloud agents — they keep receiving the original value. Adding a brand-new secret name works immediately, so this seems specific to updates and deletions of existing names.

Steps to Reproduce

  1. Add a secret in Cloud Agent Secrets, e.g. CLERK_SECRET_KEY, scoped to All Repositories. Launch a cloud agent and confirm the value is injected into the shell env.
  2. Edit that secret to a different value and save. Launch a new cloud agent — it receives the old value.
  3. Delete the secret row entirely and save. Confirm it’s gone from the dashboard list. Launch a new cloud agent — it still receives the old value, and the name still appears in CLOUD_AGENT_INJECTED_SECRET_NAMES.

Expected Behavior

An updated secret injects its new value into the next agent. A deleted secret is not injected at all and disappears from CLOUD_AGENT_INJECTED_SECRET_NAMES.

Operating System

MacOS

Version Information

N/A — reproduced entirely on the Cursor web platform (cursor.com dashboard for Cloud Agent Secrets) and the Cloud Agent API (api.cursor.com/v0). No IDE, CLI, or iOS app involved. Repro timestamps: 2026-08-01 02:13–03:00 UTC.

Additional Information

Verified across 6 separate cloud agents over ~50 minutes, launched via the Cloud Agent API on a Next.js repo.
Compared prefix, length, and last 4 characters of the injected env var on every run — byte-identical each time, through multiple edits and then a full delete.
Still injected 7 minutes after deletion, so not propagation lag.
Two secrets affected (NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY, CLERK_SECRET_KEY). For contrast, three newly added secret names propagated to agents immediately, and one other pre-existing secret (NEXT_PUBLIC_SITE_URL) did successfully take an updated value — so the staleness isn’t fully consistent, which might help narrow it down.
No .env or .env.local on the agent machine and no .cursor/environment.json in the repo, so Cloud Agent Secrets is the only possible injection source.
Security impact: I had no way to revoke credentials from cloud agents. Deleting them in Cursor did nothing, so I had to rotate the keys at the identity provider. In effect, any secret ever added to Cloud Agent Secrets should be treated as permanently granted until rotated at its source.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @justincarlson
To clear the stale and deleted values now: open that environment in your Cloud Agents dashboard and start a New Setup Run (managing environments). Once the fresh build finishes, new agents stop receiving the old and deleted values.

This isn’t intended behavior or anything you misconfigured, so rotating those keys at your identity provider was the right call. It’s an issue we’ve been actively addressing - how secrets apply to new agents has recently changed so edits and deletions take effect going forward.

If an agent launched after the new build still shows an old value, reply with its ID and I’ll dig in.