Cloud Agents API: auto-created PRs switched from ready-for-review to draft around July 11 (no client-side change)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

We dispatch Cloud Agents from CI via POST https://api.cursor.com/v1/agents to auto-fix nightly Docker build failures in a private repository, with autoCreatePR: true and skipReviewerRequest: true.

On July 10, 2026 and earlier, the PRs auto-created by these agents were opened ready for review. On July 11, 2026, with a byte-identical request payload, the PR was auto-created as a draft. Nothing changed on our side between those runs (the dispatching workflow’s last modification was July 8, and three ready-state PRs were created after that change).

Evidence, determined from the GitHub timeline API (ReadyForReviewEvent / ConvertToDraftEvent), i.e. creation state, not just current state:

  • June 15 – July 10: 15 consecutive auto-created PRs opened ready for review (zero draft-conversion events on any of them).
  • July 11: PR auto-created as draft, no conversion events.
  • Historical note: before ~June 12, the same integration consistently opened PRs as drafts (15 of 15 from mid-May to June 11). So this is the second unannounced flip of this behavior we’ve observed.

Agent IDs, all from the same integration with identical payloads:

  • bc-1aa0cfa7-e069-44f6-8b2a-b655d2a3b518 — July 10, PR created ready
  • bc-53976078-f231-4492-aeac-35ee3e75c647 — July 10, PR created ready
  • bc-8e717e5d-b038-470f-ab8f-092a2b8776e9 — July 11, PR created draft

In all cases the PR was created mid-run (the agent was still working when the PR appeared), so run phase doesn’t explain the difference.

Steps to Reproduce

  1. POST https://api.cursor.com/v1/agents with:
    {
  "prompt": { "text": "<fix instructions>" },
  "repos": [{ "url": "<private repo>", "startingRef": "main" }],
  "autoCreatePR": true,
  "skipReviewerRequest": true
}
  2. Let the agent commit and push; Cursor auto-creates the PR mid-run.
  3. Check the PR’s draft state at creation (GitHub timeline API shows no conversion events, so current state = creation state).

Through July 10 this reliably produced a ready-for-review PR; from July 11 it produces a draft.

Expected Behavior

Draft-vs-ready state of auto-created PRs should be stable and documented — ideally an explicit request parameter on the Create Agent endpoint. The API docs describe autoCreatePr only as “Whether Cursor should open a pull request when the run completes”, with no draft/ready contract, so integrations can’t rely on either behavior. Related requests exist in both directions (URLs in backticks — new forum accounts are limited to 2 links per post):

  • https://forum.cursor.com/t/open-pr-in-draft-mode-from-cloud-agent/140461
  • https://forum.cursor.com/t/cursor-automations-only-creates-pull-requests-as-drafts/159295

Questions: Was there a server-side change around July 10–11? Is draft-at-creation the intended behavior going forward?

Operating System

Other

Version Information

N/A — Cloud Agents API (api.cursor.com/v1/agents); no IDE involved

Additional Information

Possibly related: our agent prompt runs gh pr ready as a safety net after the PR is auto-created. On the July 11 run this had no effect — GitHub logged no ready-for-review conversion — while gh pr edit (label/title/body) from the same agent session worked fine. This looks like the GitHub App token being unable to run the markPullRequestReadyForReview mutation, similar to https://forum.cursor.com/t/pull-request-create-failed-graphql-resource-not-accessible-by-integration-createpullrequest/153425

If draft is now the default, agents need a working way to convert their own PRs to ready — otherwise unattended pipelines have no way to produce a reviewable PR.

This involves a private repository, so repo name and PR links are omitted here — happy to DM them to staff.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Seeing the exact same thing, our Linear-assigned Cursor agents started opening drafts instead of ready-for-review around July 11 with no config change on our end. +1 for an official response and a toggle.

6

Hey there!

Thanks for the report!

The way it’s supposed to work (and on our side, how it’s worked for a long time) is that Cloud Agents, by default, open a Draft PR. However, the Agent can be instructed to mark the PR as Ready for Review.

Because this behavior is promptable, it’s inherently non-deterministic. The good news is that it’s easy to influence without us needing to add a setting. You can try adding something like “raise a PR and mark it as ready for review” to your prompt.

That said, we want to keep looking into this. On our end, I do see some GitHub API errors coming from the background task ID that you mentioned was raised as a draft, so there may be more going on here. I’d encourage you to try running it again and see if the behavior has changed.

To help us investigate further, could you also share a bc-ID from the URL of an affected Cloud Agent? It would be great if you could share one from around July 11, and another from today. That would let us compare the behavior across those dates and dig into what changed.

8

Thanks Colin — fresh data from last night that sharpens this, including the bc-IDs you asked for.

Our nightly dispatched two agents from the same integration ~2 minutes apart, with byte-identical API payloads (autoCreatePR: true, skipReviewerRequest: true):

  • bc-467ecc9d-6efb-4b55-89b6-5e2405885136 — PR created 2026-07-15T00:29:25Z, ready for review at creation. GitHub’s timeline shows zero ready-for-review conversion events, so this was not the agent marking it ready afterwards — the PR was born non-draft.
  • bc-3abfb00d-9b7d-4b05-8d46-b106d187dda8 — PR created 2026-07-15T00:31:38Z, draft at creation, never converted.

So at least for API-dispatched agents, the non-determinism is in the creation state of the auto-created PR itself, not only in whether the agent follows a “mark it ready” instruction.

On the promptable workaround: our prompt already does exactly that — gh pr ready immediately after a gh pr edit. On the draft run above, the agent demonstrably executed the adjacent gh pr edit (label landed 3 seconds after PR creation) and completed its full run (CI green, success comment posted), but the ready conversion left no trace on GitHub. That matches the GitHub API errors you saw on bc-8e717e5d-b038-470f-ab8f-092a2b8776e9 (July 11). Could you check the transcript of bc-3abfb00d-9b7d-4b05-8d46-b106d187dda8 for the same error — specifically whether markPullRequestReadyForReview is failing for the app token? If so, the prompt-side workaround can’t work by construction.

Full bc-ID set for comparison, all one integration, identical payloads:

  • July 10, born ready: bc-1aa0cfa7-e069-44f6-8b2a-b655d2a3b518, bc-53976078-f231-4492-aeac-35ee3e75c647
  • July 11, born draft: bc-8e717e5d-b038-470f-ab8f-092a2b8776e9
  • July 15, born ready: bc-467ecc9d-6efb-4b55-89b6-5e2405885136
  • July 15, born draft: bc-3abfb00d-9b7d-4b05-8d46-b106d187dda8
9

Hi @fd_r

The transcript isn’t available to us due to Privacy Mode restrictions.

Instead of asking the agent to run specific commands, could you try telling the agent to open the PR as “Ready for Review” rather than “Draft”? The “happy path” for opening a PR in a Cloud Agent doesn’t use the GitHub CLI, but directly hits GitHub’s API.