For some requests we see intermittent issues with the API failing with a 400 error and giving this error message “Failed to determine repository default branch”
Othertimes it’s working just fine and properly identifying the default branch.
Why would it fail to find the default branch? Our workaround is to specify the branch directly, but this is a worse UX.
Steps to Reproduce
Call the API for launch an agent and observe the error. I don’t have a good way to “force” it to happen, as I said, it’s intermittent.
Hey, thanks for the report. This looks like a separate issue from the OpenAPI spec bug you reported earlier. In this case, branch detection itself is failing sometimes.
To help the team figure out what’s going wrong, could you share:
Is this happening in one specific repo or across multiple repos?
About how often does it fail vs work?
The full API response body and timestamps from a couple of failed calls. That’ll help us match them to our logs.
Specifying the branch directly is a good workaround for now. I know it’s not ideal though.
I’m flagging this with the team. Let me know if you can share those details.
I don’t have the full API responses handy currently.
I did notice that manually specifying branches actually isn’t working either, in those cases we see:
```
Cursor API error (400): Failed to verify existence of branch ‘master’ in repository org/repo. Please ensure the branch name is correct.
```
The only thing that seems to work is waiting.
Here are some logs from our system that might help with correlation though:
```
level: error
message: Cursor API error: Failed to determine repository default branch
statusCode: 400
timestamp: 2026-02-27 16:21:09
level: error message: Cursor API error: Failed to verify existence of branch ‘master’ in repository org/repo. Please ensure the branch name is correct. statusCode: 400 timestamp: 2026-02-27 16:33:09
Hey, I can see the situation got worse. The fact that even explicitly specifying the branch stopped working (“Failed to verify existence of branch ‘master’”) suggests the issue isn’t branch detection itself. It’s more likely GitHub token resolution on our side.
The timestamps you shared (2026-02-27 16:21:09 and 16:33:09) will help. If you can also grab the Request ID for at least one failed request, that’d speed up debugging a lot. You can find the Request ID in the URL on cursor.com/agents.
I’ll pass this to the team. For now, the only workaround is to wait and retry, like you noticed. I’ll let you know if there are any updates.
I don’t see the failed attempts on the dashboard. I’m starting these agents using the API, which I think must mean it never appears in my actual history on cursor.com/agents since it fails.
Hi @ahar — thanks for the detailed logs and timestamps; they were exactly what we needed.
Good news: we tracked down the root cause, and a fix has been merged. The intermittent “Failed to determine repository default branch” and “Failed to verify existence of branch ‘master’” 400s were coming from transient GitHub conditions (rate-limiting / brief unavailability) being treated as permanent branch-resolution failures, plus an unrelated cache-write hiccup that could abort an otherwise-valid request. We now surface those transient cases correctly and no longer fail the request on a cache miss — which lines up with what you saw, where simply waiting and retrying worked.
This is a backend change on our side, so there’s nothing to update in your Cursor client — it’ll take effect as the fix rolls out to our servers. Over the next day or so, could you check your API logs and let us know whether those errors (both variants) have stopped? If they’re gone, you’re all set; if you still see them, drop a recent timestamp or Request ID and we’ll dig back in.