Feature request for product/service
Cloud Agent (GitHub, Slack, Linear,…)
Describe the request
I run Cloud Agents from GitHub Actions through the Cloud Agents API (POST /v1/agents). The driver is autonomous: a push to my default branch (develop) should be enough for the next run to pick up new .cursor/agents cards and Cursor rules.
The agent itself starts on a feature branch (feature/package-module-boundary). The environment Build is a separate snapshot of the default branch. A new agent forks the last Build with status Success. That old snapshot is what the VM gets in both of these windows:
- The push is already on
develop, but the next recurring check has not started a Build yet. - A Build has started, but
installhas not finished, so it is not the active one.
Agents started in either window load subagent definitions and rules from the old disk. After startup the agent checks out the feature branch, and git shows the new files. The workspace looks up to date. The agents still follow the previous cards.
What I need
A way to ask, with the same API key I use to create agents, and before any VM starts:
- Which Build is active for this environment?
- What is its status (running, success, skipped)?
- Which commit SHA did it record for each repository?
Then my driver can wait until that SHA contains the commit I just pushed, and only then call POST /v1/agents. No agent, no tokens, just a read.
Even better: a field on create that names the commit the active Build must already contain. If it does not, return 409 with the active SHA. The client sleeps and retries.
What happened
I had set readonly: true on three custom subagents (tester, verifier, plan-reviewer) in .cursor/agents/. In a Cloud Agent that frontmatter forces Ask mode, so the shell never ran PHPUnit, PHPStan, or grep. I removed readonly and merged that to develop. The next agent, on feature/package-module-boundary, already had the new files. The subagents were still read-only, because that run forked the older environment Build.
Times are local (UTC+2), 22 Sept 2026. This is the Builds list for that environment, opened while the selected branch was feature/package-module-boundary. The rows are still the recurring default-branch snapshots. The dashboard truncates the ids.
| Time | Build | What happened |
|---|---|---|
| 01:46 | bld-20260921-cf40ea1e-cead-4419-aa1b-… Success |
This snapshot still has readonly: true. |
| 02:41 | Execute agent starts from that Build. | |
| 03:44 | Same failure again. Tester is in Ask mode. | |
| 04:00:41 | Merge to develop that removes readonly. |
|
| 04:04:55 | New agent starts: bc-e6578644-388d-4992-84c5-c78f7caef5ea, on feature/package-module-boundary. It still forks the 01:46 Build. |
|
| 04:05 | bld-20260922-766a177b-7751-49da-8fc5-… Success |
The Build that contains the merge starts. |
| 04:14 | I cancel the job. The 04:05 Build was never the one this run used. | |
| 05:14–11:02 | recurring | Skipped. develop had not moved again, so the active Build stayed the one from 04:05. |
The damage was the run that started one minute before the 04:05 Build existed.
Why the current controls do not close this
- The Builds tab shows the commit SHA. My driver cannot read it.
POST /v1/agentsdoes not return the Build id or the SHA the machine was forked from. list-environment-buildson the Cursor Cloud MCP runs only inside an agent that has already booted. That is the call I am trying not to make.- Update stale builds can pull newer default-branch code at startup. The runtime has already read
.cursor/agentsand the rules from the Build disk by then. Checking outfeature/package-module-boundarydoes not reload those cards for that session. I hit the same behavior described here: Cloud agents: file-read tool serves stale default-branch content. Staff confirmed there that subagent cards are loaded once at session start from the Build, and that a new Build is what makes new cards take effect.
So the only check I can do today is to start an agent, read the local default-branch ref (that ref is the Build commit), and exit if it does not contain origin/develop. That spends a VM to learn a SHA the Build already recorded. If I relaunch immediately, the new agent forks the same Build and reports the same line.
Request
Please add a Builds read to the public Cloud Agents API, authenticated like POST /v1/agents:
GETthe active Build for an environment: id, status, start time, and the commit SHA per repository.- Optionally, let
POST /v1/agentsaccept the commit that must already be in that Build. A409with the active SHA is enough. The client can sleep and retry.
That is the missing piece for an autonomous workflow. I already know which commit I pushed. I cannot know whether the environment I am about to start was built from that commit. Guessing with a sleep, or booting an agent to look, is not something I can rely on when every early start loads stale subagent settings and burns a full run.
Operating System (if it applies)
Windows 10/11