Where does the bug appear (feature/product)?
Cloud Agent (GitHub, Slack, Web, Linear)
Describe the Bug
Every background cloud agent on my account has frozen part-way through and never reached a terminal state. Sixty consecutive agents. It began at a specific minute on 18 August and has not stopped.
This is the cloud agent service dispatched through the REST API, not the desktop IDE, so IDE version and OS are not meaningful here.
THE SIGNATURE, identical every time:
- POST /v1/agents returns 201. The agent is created normally.
- It starts and does real work. Most push genuine commits to their branch.
- Its updatedAt then freezes to the millisecond and never advances again.
- status stays ACTIVE indefinitely, for hours and then days.
- autoCreatePR: true never produces a pull request, because completion is never reached.
EVIDENCE from GET /v1/agents?limit=60, read 2026-08-20:
| Agent | Ran for | Then frozen for |
|---|---|---|
| bc-eabde751-932d-4708-a9ac-788d1d6e75aa | 147 min | 11 hours |
| bc-5e4e25ad-a050-4559-a391-9becd116552e | 148 min | 11 hours |
| bc-a18d2f6f-35… | 8 min | 14 hours |
| bc-5a933bee-10… | 51 min | 15 hours |
| bc-a28c0a08-a6… | 1359 min | 18 hours |
59 of the 60 agents returned are in this state. The first affected is bc-a28c0a08, created 2026-08-18T15:47:33Z. Everything created before that timestamp completed normally.
NOT THE SAME AS EXISTING REPORTS. I have read the older threads about agents stuck in “starting” or “initialising”. This is not that. These agents start successfully, run for up to 2 hours, push real commits, and then freeze mid-task with status still ACTIVE.
Steps to Reproduce
- Dispatch a cloud agent: POST to the v1/agents endpoint on the Cursor API, with a normal brief, a GitHub repo, startingRef main, and autoCreatePR true. Returns 201.
- Poll GET v1/agents?limit=60 every few minutes.
- Watch the agent’s updatedAt advance normally while it works. Check the target branch: real commits appear.
- At some point between 1 and 1359 minutes after creation, updatedAt stops advancing and never moves again.
- status remains ACTIVE indefinitely. No pull request is ever created. No terminal state is ever reached.
Reproduces on every dispatch, on six different repositories, with unrelated briefs written at different times.
WHAT I HAVE ALREADY RULED OUT BY MEASUREMENT:
- Not brief quality or repository-specific: affected agents span six repositories with completely unrelated instructions.
- Not dispatch refusal or capacity: creation returns 201 and the agents genuinely start and do work before freezing.
- Not one long task hitting a timeout: freeze points range from 0.8 minutes to 1359 minutes after creation, with no pattern.
- Not a GitHub Actions problem on my side: a separate GitHub-side issue on my account has a measured onset roughly six and a half hours later, on a different clock.
ONE CLUE: a dispatch on 2026-08-19 at 03:31Z returned HTTP 429 from get_installation_for_org. That is a GitHub-integration call rather than a Cursor-capacity one, which keeps the Cursor-to-GitHub App installation in the frame as a possible cause.
WHAT I CANNOT SEE AND YOU CAN: the per-agent conversation endpoint returns 404 on this API version, so I have no access to the agents’ own logs. Everything an API key can read has been read.
Expected Behavior
The agent reaches a terminal state: it finishes its task, status changes away from ACTIVE, and with autoCreatePR: true it opens a pull request. This is what happened on every dispatch before 2026-08-18T15:47:33Z.
At minimum, an agent that cannot continue should FAIL rather than sit at ACTIVE forever. A stuck agent that reports ACTIVE is indistinguishable from one that is still working, so there is no way for a caller to detect the fault or to decide when to give up and retry. That is the part that has cost the most: I dispatched replacements for what I thought were four separate one-off stuck agents before measuring and realising it was one account-wide fault, twenty-one times over.
WHAT I AM ASKING:
- Please look at the server-side log for bc-eabde751-932d-4708-a9ac-788d1d6e75aa, the most recent, and say at what point and why it stopped.
- Is this a platform regression, something specific to my account or plan, or my Cursor-to-GitHub App installation?
- Should I uninstall and reinstall the GitHub App? Would that affect the 60 stuck agents?
- Am I being charged for agents that never completed? I am on Pro+.
Has anyone else seen agents freeze with status stuck on ACTIVE since 18 August? If this is account-specific I will chase it differently, but the onset is clean enough that I suspect it is not.
I have paused all further dispatches rather than create more stuck agents.
Operating System
Windows 10/11
Version Information
Not applicable: this is the Cloud Agent service driven through the REST API, not the IDE or CLI. No local Cursor version is involved in the fault. Plan: Pro+. API version: whatever v1 currently serves (note that the per-agent conversation endpoint returns 404 on it).
For AI issues: which model did you use?
Various, and the fault is model-independent: affected agents were dispatched on claude-sonnet-5, claude-opus-4-8 and composer-2.5. All froze identically.
For AI issues: add Request ID with privacy disabled
bc-eabde751-932d-4708-a9ac-788d1d6e75aa (most recent, ran 147 min then froze). Also: bc-5e4e25ad-a050-4559-a391-9becd116552e, bc-a28c0a08-a6… (first affected, created 2026-08-18T15:47:33Z). 60 agent IDs available on request.
Additional Information
To be precise about the severity answer above: the IDE is completely fine, so I have not marked Cursor unusable and I do not want to overstate this. But the Cloud Agent feature specifically has a 100 percent failure rate on my account, 60 out of 60 since 18 August. Nothing is intermittent about it. I chose “sometimes” only because the IDE works.
Impact in practice: I cannot run unattended or parallel build work at all. Every job now has to be done interactively instead, which is a throughput loss rather than a stoppage.
The most useful agent for you to inspect is bc-eabde751-932d-4708-a9ac-788d1d6e75aa. It is the most recent, it ran for 147 minutes doing genuine work with real commits pushed, and then stopped dead. If you would like the full list of all 60 agent IDs with their created and updated timestamps I am happy to post it.
Repositories affected (all in one GitHub organisation): six different ones, with unrelated briefs. Happy to name them privately if that helps you correlate against your logs.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor
