The agent opened a pull request and a check on it failed. Somebody now has to come back to the work: open the build log, understand the cause, add a commit. Cursor closes that loop onto the agent itself - cloud agents try to fix failed checks in the pull requests they created. GitHub Actions is supported today, and this is not a separate mode enabled per task but default behavior that comes with an off switch.
The first impulse is to let the automation fix everything that is red. It is a natural one, because a red check looks the same regardless of the cause: the interface shows a cross, and the cross does not reveal whether this pull request broke it, or somebody else's commit, or a stalled runner. Since the outward result is identical, it seems logical to make the reaction identical too and sort out the cause while fixing.
This breaks on the origin of the failure. A noticeable share of red checks has nothing to do with the change: the same check was already failing on the base commit, the test turned out to be flaky, an external service did not answer. An agent that takes on such a failure writes commits into nowhere, and sometimes bends the code around somebody else's breakage. The second origin is worse: a human may have pushed to the branch, and then the automation starts editing on top of live work whose intent it does not see in full.
So the loop is described less by what it does than by what it does not touch. It stays silent if a new human commit landed on the branch - agents do not fix failures on human commits. It stays silent if a person sent the agent a follow-up message. It stays silent if the same check is already failing on the base commit of the pull request. And it stays silent if this pull request has already had ten build-failure follow-ups. Below is that list in full:
The follow-up limit stands apart from the other conditions, because it bounds volume rather than origin. All the other rules answer the question of whose failure this is; the tenth follow-up answers the question of how many attempts are reasonable. Automatic repair of a check is a feedback loop: a commit starts a build, the build produces a result, the result starts the agent. A loop without a counter can spin until somebody notices, and the limit here is not a settings detail but a safety condition for the whole construction.
| Event | Loop behavior | Reason |
|---|---|---|
| A GitHub Actions check failed in the agent's pull request | The agent takes on the fix itself | The failure belongs to its own change |
| A human commit landed on the branch | The loop stays silent | The automation does not act on human commits |
| A person sent the agent a follow-up message | The loop stays silent | A human is driving the work again |
| The same check is failing on the base commit | The loop stays silent | The failure was not caused by this pull request |
| The pull request has already had ten failure follow-ups | The loop stays silent | The follow-up limit is exhausted |
| A comment asking to fix the failures | The agent fixes on request | An explicit human command, including about a specific check |
| The comment @cursor autofix off | The loop is disabled for this pull request | A targeted opt-out without editing global settings |
The manual path remains open. The agent is called by a comment on the pull request and asked to fix the failures, and a specific check can be named, a failing linter for instance. The difference is practical rather than cosmetic: a targeted request narrows the area, and the agent does not start working through the whole build matrix for the sake of one line. The same path helps when the automation stayed silent because of one of its conditions while the fix is still needed.
All of this is turned off at two levels. Entirely for your own cloud agents - in the Cursor dashboard, in the cloud agents section, in personal settings, where the option for automatically fixing build failures is cleared. Pointwise for a single pull request - by the comment @cursor autofix off, and back on by the comment @cursor autofix on. In practice the second level matters more than the first: it lets you avoid disabling a useful loop for good because of one pull request where the automation is in the way.
The price comes in three parts. Every follow-up is an agent run and then a full build run, which is minutes and money; ten follow-ups on a single pull request is already a noticeable figure, especially on long matrices. Next comes noise in the branch history: a series of corrective commits on top of a meaningful change reads worse than a single one. And above all there is the risk of bending: an agent whose success criterion is stated as a green check is entitled to make it green by any means, including weakening the check itself.
The loop pays off where failures are numerous and mechanical: formatting, the linter, types, a forgotten snapshot, a generated file that was not rebuilt. On such failures it saves exactly the kind of attention that is spent for nothing. In projects where the build is unstable on its own, enabling it before fixing the instability is pointless - it will be repairing the weather. The result is verified not by the color of the badge but by the contents of the corrective commits: look at what actually changed after the automatic repair, and look separately at whether the tests themselves, the coverage thresholds and the linter configuration were touched.
Availability is worth remembering separately: the loop is rolled out to team accounts, for the rest it is announced as coming, and planning a process around it before then is premature. The typical failures are predictable. Enabling the automation on a project with flaky tests and getting a series of follow-ups on every pull request. Taking a green badge as proof without reading the corrective commits. Pushing your own commit to the agent's branch and expecting it to keep fixing - after a human commit the loop stays silent by rule, not by mistake. Turning the mechanism off entirely because of one noisy pull request instead of a targeted comment. And leaving the agent free to edit the check configuration, then being surprised that a failing test disappeared instead of passing.