Cloud Agent ignored an explicit “work on existing PR # and don’t create a new branch or PR” instruction (both in AGENTS.md and a cursor .mdc rule). Instead it followed the “cloud-agent branch/PR template” and created a new branch and a draft PR.
Steps to Reproduce
Open an existing feature PR (feature/my-feature).
Start a Cloud Agent with an instruction to continue closeout work on that existing branch/PR, and not create a new branch or PR.
Ensure a workspace/repo rule exists forbidding new branches/PRs without an explicit ask (this repo has .cursor/rules/no-branch-or-pr-without-approval.mdc, alwaysApply).
Ask the agent to expand the scope of the implementation somewhat and handoff.
Expected Behavior
Agent commits/pushes on feature/my-feature so changes land on existing PR. No new branch. No new PR. If unsure, ask before creating either.
Cloud agents started from the Agents Window are designed to work on their own feature branch (cursor/<name>-<id>) off a base branch, and the harness’s per-turn “create or update the PR” instruction is treated as mandatory. Because those come from the harness itself, they win against AGENTS.md, .mdcalwaysApply rules, and explicit “don’t create a new branch/PR” instructions in the chat - which is why you got cursor/313-working-book-review-fixes-8425 and draft PR #363 instead of commits on #323’s feature/313-working-book. Not intended for cases like yours, and it’s an issue we’re tracking.
The one supported way to keep a cloud agent working on your existing PR branch is to trigger it from the PR itself: on GitHub, comment on PR #323 with @cursor <your instruction>. Agents started that way skip the auto-branch template and commit directly to the PR’s head branch (feature/313-working-book).
For the cleanup you asked about: yes - closing #363 and moving those commits onto feature/313-working-book will land them on PR #323, which is what you want.
I understand, but it doesn’t help if the Cursor harness tries to force users into a specific workflow or way of working.
Because of this, I have started to tell Cursor cloud agents to ignore anything in their harness related to creating new branches or opening PRs, and that has worked. It’s not an insurmountable issue. It just creates noise and spends tokens when I have to tell Cursor cloud agents to delete their branch and move to a new one.
This is super annoying, and it’s getting in the way of using cloud agents as the main workflow.
Cursor has been writing that the next era of agent development is all in the cloud. I’m bought in. I write over 75% of my PRs with cloud agents now. I need more control over when those PRs actually get opened.
The Create PRs setting is the problem. It’s Never or Always, and those are both pretty extreme. Never means the agent can’t open a PR even when I want one. Always means every turn with a change tries to open or update a PR, which burns CI and dumps half-ready PRs on people. There is nothing in the middle: let the agent create a PR when the work is actually done, or when I ask, without forcing one every time.
Prompting around the harness is unreliable, and I see this behave differently depending on which model is running. A middle option here would make cloud agents much easier to use as a daily driver.
@tobias.counsel this is fair, and you’re not the only one in this thread asking for it. A cloud agent opens or updates a PR every turn that has a change, and there’s no “open the PR when the work is actually done, or when I ask” option in between. That middle ground, and making the every-turn push cadence configurable so it stops storming CI, is something we’re tracking. No timeline to share, but this thread is a useful signal for prioritization, so if others want it too, add your workflow here.
One lever that helps today if you want an agent to keep working on an existing PR rather than spin up a new one: comment @cursor <instruction> on the PR itself. Agents started that way commit straight to that PR’s branch instead of creating a new branch and PR.
