Cloud Agent environment never sets Active Build — 7 successful builds, manual activation doesn't stick

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

My Cloud Agent environment has shown Active Build: — and Active Build Status: — all day, across seven successful builds. Environment e/3154ee39-957a-11f1-ba66-0e7d0216e441, repo cwokral-beep/madonna, Personal scope, .cursor/environment.json with no snapshot and no build.dockerfile.

The docs say a successful Build becomes active. Four of the seven are Recurring builds with no Draft badge — those should have activated on their own. They didn’t.

I also activated one manually from the Builds tab (bld-20260820-797ebc3d-0036-4b7e-8e0f-580dab2c012b, Agent, Success). Its Draft badge cleared and stayed cleared through a hard reload, so the activation stuck to the build — but the Overview panel still reads —, hours later. So it isn’t a stale render.

On my side: environment.json validates against your published schema, every field and type; my install command exits 0 on all seven builds and is idempotent.

The thing that looks most diagnostic: there is no snapshot phase anywhere in the build log. I downloaded the full log for 797ebc3d. It goes environmentSetup → gitCheckout:clone → your install:* steps → start:core-dumps/desktop-init/exec-daemon → [SPAN] Ended: environmentSetup, then my install command runs, then [INSTALL] Exit code: 0 and the log ends. Nothing after.

Related symptom: every build installs PostgreSQL from scratch and applies all migrations as pending, so no disk state carries between builds.

Is the Overview field failing to read activation state, or is the environment genuinely running without an active build? And should a snapshot span appear in the log? Happy to share the full log — nothing in it is sensitive.

Steps to Reproduce

My Cloud Agent environment has shown Active Build: — and Active Build Status: — all day, across seven successful builds. Environment e/3154ee39-957a-11f1-ba66-0e7d0216e441, repo cwokral-beep/madonna, Personal scope, .cursor/environment.json with no snapshot and no build.dockerfile.

The docs say a successful Build becomes active. Four of the seven are Recurring builds with no Draft badge — those should have activated on their own. They didn’t.

I also activated one manually from the Builds tab (bld-20260820-797ebc3d-0036-4b7e-8e0f-580dab2c012b, Agent, Success). Its Draft badge cleared and stayed cleared through a hard reload, so the activation stuck to the build — but the Overview panel still reads —, hours later. So it isn’t a stale render.

On my side: environment.json validates against your published schema, every field and type; my install command exits 0 on all seven builds and is idempotent.

The thing that looks most diagnostic: there is no snapshot phase anywhere in the build log. I downloaded the full log for 797ebc3d. It goes environmentSetup → gitCheckout:clone → your install:* steps → start:core-dumps/desktop-init/exec-daemon → [SPAN] Ended: environmentSetup, then my install command runs, then [INSTALL] Exit code: 0 and the log ends. Nothing after.

Related symptom: every build installs PostgreSQL from scratch and applies all migrations as pending, so no disk state carries between builds.

Is the Overview field failing to read activation state, or is the environment genuinely running without an active build? And should a snapshot span appear in the log? Happy to share the full log — nothing in it is sensitive.

Expected Behavior

Per the Builds docs, a successful Build becomes active and agents start from it. I’d expect Active Build to show the most recent successful build’s ID and Active Build Status to show its state — automatically for Recurring builds, and definitely after an explicit manual activation.

Instead both fields have stayed empty all day, and agents appear to run the full install from scratch each time rather than starting from a snapshot.

Operating System

MacOS

Additional Information

All seven successful builds, 2026-08-20 (UTC+2):

  • 09:56 Recurring — Success
  • 11:06 Recurring — Success
  • 12:15 Recurring — Success
  • 13:24 Recurring — Success
  • 13:55 Manual (Draft) — Success — bld-20260820-e9b5018c-bbb4-4bd9-93da-8bd0dbc678d2
  • 14:10 Agent (Draft) — Success — bld-20260820-797ebc3d-0036-4b7e-8e0f-580dab2c012b (the one I manually activated)
  • 16:05 Manual — Success — bld-20260820-644226e5-e670-40e8-…

Skipped Recurring checks in between behave correctly — no new commits, complete in seconds, leave the active build in place. Those aren’t part of the issue.

Impact: with no active build, every agent run re-installs the full environment from scratch — apt-installing PostgreSQL and Redis, npm ci across 15 packages, provisioning 10 databases and applying ~330 migrations — roughly two minutes before the agent does any work. That cost is paid on every single agent, which is what makes this more than cosmetic for me.

Version Information

N/A — this is the Cloud Agent web dashboard (cursor.com/dashboard/cloud-agents), not the IDE, CLI, or iOS app. Observed in Chrome on macOS on 2026-08-20.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey @Chris_Wokral, thanks for the unusually thorough report.

Good news: your environment is fine. Your builds are succeeding (including bld-20260820-797ebc3d…, which produced a valid snapshot, and your manual activation did stick), and every agent you’ve started since Aug 19 has booted from the latest build snapshot instead of re-running your install.

The “Active Build: —” field is just a display bug on the Overview panel. It hits environments that were enrolled in Builds by default rather than through the settings toggle. I’ve passed it along to the team.

Two other points:

The downloadable log stops right after your install exits, and the snapshot happens after that, so there’s nothing to see there. Expected.

That’s on purpose. Each build starts from a clean base and runs your full install, which is what keeps builds reproducible, so Postgres reinstalling every time is expected. Agents are the ones that skip the install by booting from the finished snapshot, and yours are doing that.

8

Thanks Colin — and for replying so quickly. I really appreciate it.

That’s a relief on all three counts. Good to know the snapshot was there the whole time; I’d built a working theory that my install leaving PostgreSQL running was blocking it, and had already changed the install to stop it. I’ll be reverting the part of that change that was premised on your side being broken rather than mine.

Two follow-ups if you have a moment:

  1. While the Overview field is unreliable, is there anything on the agent side that shows which snapshot a given agent actually booted from? Something in the agent’s own startup log would let me confirm it directly rather than inferring from the absence of install output.
  2. Is there a way to re-enrol the environment through the settings toggle so it lands in the state that displays correctly, or does that need the fix to ship?

Happy to leave the topic open until the display bug lands if that’s useful for tracking.

12

Good questions!

You can open any agent on cursor.com and look at the environment line in its setup section.

Screenshot 2026-08-21 at 15.28.44
Screenshot 2026-08-21 at 15.28.441254×532 55.8 KB

Screenshot 2026-08-21 at 15.28.55
Screenshot 2026-08-21 at 15.28.551076×688 43.2 KB

This reads the agent’s own boot record, so it isn’t affected by the Overview display issue.

Not currently possible, I’m afraid. For environments enrolled by default the toggle is hidden, so there’s no way to land yourself in the state that displays correctly.