When using BugBot’s “Fix in web” feature, after selecting a specific branch and clicking “Push to branch”, the automation always opens the PR against the default branch (e.g., develop) instead of the branch where the bug was actually found. This means the fix lands in the wrong branch, the PR is completely misplaced, and we get charged for an automation run that doesn’t actually fix anything in the right place.
Steps to Reproduce
Open a GitHub repository connected to Cursor BugBot.
BugBot identifies a bug on a non-default branch (e.g., a feature branch like hey-4552-intelligent-hangup).
Click “Fix in web” on the BugBot suggestion.
In the branch selector, choose the specific branch where the bug was found.
Click “Push to branch” to trigger the automated fix.
Observe that a PR is created — but it targets the default branch (e.g., develop) instead of the selected branch.
Expected Behavior
When a branch is selected in the “Fix in web” UI and “Push to branch” is clicked, the resulting PR should target the selected branch (the one where the bug was found), not the repository’s default branch. The branch selection setting should be respected by the automation.
Hey, thanks for the detailed report. This is a confirmed bug on our side. The Fix in web page loads the selected branch info from the deeplink asynchronously, and if you click Push to branch before loading finishes, the agent falls back to the default values and creates a new cursor/* branch and targets the PR to the repo default branch, like develop. So it’s not ignoring your settings, it’s a race condition at submit time.
The issue is reported and tracked internally. I can’t share an ETA for a fix yet.
A workaround that reliably avoids the issue:
After opening Fix in web, wait a few seconds about 10s for everything to load before clicking Push to branch, or
Open the branch dropdown once before submitting. This forces the branch to resolve, and the PR goes to the right place.
Both options consistently produce the correct branch in our tests. Let me know if you can still reproduce it with this, and we’ll dig deeper.
Hey @deanrie , I’m already doing that, waiting a few seconds till the actual branch shows up, then waiting a few seconds more and it’s still selecting the develop branch!
Hey @Luisa, got it. And yeah, we already know about this bug and have confirmed it. Fix in web targets the PR to the default branch develop instead of the branch you picked. We’re already tracking this.
What’s odd in your case is that the workaround (wait for it to load, or open the dropdown) usually avoids it, but it doesn’t for you. That might be a different scenario we haven’t reproduced yet, and I want to check it against a specific run.
Can you share:
A link to the agent on cursor.com/agents (the URL is fine, it includes the run ID).
A screenshot of the Fix in web page right before you click Push to branch, so we can see which branch is selected in the dropdown at submit time.
After you run it, does it create a new cursor/... branch, or does the commit go straight to develop? And at the moment you clicked, was the dropdown set to hey-4552-intelligent-hangup or develop?
With that info, we can confirm whether this is the same issue or a new one.
I stopped using this feature a while ago, cause it was happening all the time and it was just consuming resources.
But to answer number 3 the dropdown was set to hey-4552-intelligent-hangup and then I immediately pressed on it. It creates a new branch with the cursor and then creates a PR in draft againts develop!
Thanks for replying, and I get why you dropped the feature. If it’s consistently burning resources and putting the fix in the wrong place, that makes sense.
One important detail from your description is that the dropdown showed hey-4552-intelligent-hangup, but you immediately pressed it. Even if the correct branch is already visible in the dropdown, the background fetch might not have finished resolving yet. If you click instantly, the request can still go out with the old values, which is why you end up with a new cursor/* branch and a draft PR against develop.
Try this instead: open Fix in web, wait until the branch shows up in the dropdown, click the dropdown itself once (this forces it to resolve), then wait a couple of seconds and only then press Push to branch. If it still doesn’t help, then it’s likely a different case we haven’t reproduced yet.
To debug a specific run, send the link to the run from cursor.com/agents (the run ID is embedded in the URL). With that, we can check which branch actually got sent in the start-request and figure out if it’s the same bug or a new one.
Glad to hear the issue hasn’t happened again over the last few days. Sounds like the dropdown sequence is working as expected.
We’re still tracking the bug, so you won’t need to keep doing the workaround manually after the fix. For now, just keep using it so the PR always goes to the right branch. If it comes back, send the link to the run from cursor.com/agents and we’ll look at that specific case.
