[validation_error] Failed to verify branch 'Dev' on Bitbucket Cloud — integrations shows Connected, Taskmaster/API token can list branches

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

I am building a tool based on the SDK. I have been creating Cloud Agents for about 2 weeks with my tool and nothing has changed. I was checking in code and merging last night into my BitBucket repos. Today I tried to spin up a cloud agent and I got the error “[validation_error] Failed to verify existence of branch ‘Dev’ in repository (my repo). Please ensure the branch name is correct.”

I have verified.. it is there. I can see it in BitBucket, I can check in code to it locally. It cannot see Master or Dev. I tried revoking and re-connecting the OAuth for BitBucket inside Cursor and Bitbucket.

Here is info from Cursor for troubleshooting.

Cloud agents fail to start on private Bitbucket Cloud repos even though Integrations shows Bitbucket as Connected.
Reproduction (@cursor/sdk, same as our production worker):

  1. API key valid: GET (removed due to post link limits) → 200
  2. Agent.create with cloud.repos:
    { “url”: “(removed due to post link limits)”, “startingRef”: “Dev” }
  3. agent.send(“Reply OK”) fails in ~300–1000ms:
    [validation_error] Failed to verify existence of branch ‘Dev’ in repository (removed due to post link limits). Please ensure the branch name is correct.
    Same error for startingRef “master” and “main” on the same repo.
    Affected repos (all fail the same way)
    Bitbucket Integrations UI shows Connected for the same Cursor account that owns API key crsr_835… (full key available privately).
    Separately, our Atlassian API token can list branches via Bitbucket REST API (Dev and master both exist). Taskmaster merges/branch lists work. Only Cursor’s branch verification on send() fails.
    Cursor.repositories.list() returns 0 repos. No active bc-* agents to resume — every job needs a fresh create.
    This worked for ~2 weeks with no config changes on our side.

Steps to Reproduce

  1. On cursor.com → Integrations, connect Bitbucket Cloud for the same Cursor account that owns the API key (dashboard shows “Connected”).

  2. Confirm the API key works:
    GET (removed due to post link limits)
    Authorization: Basic <API_KEY>:
    → HTTP 200

  3. Create a Cloud agent via @cursor/sdk (or POST):

    const agent = await Agent.create({
    apiKey: “<API_KEY>”,
    model: { id: “auto” },
    cloud: {
    skipReviewerRequest: true,
    autoCreatePR: false,
    workOnCurrentBranch: false,
    repos: [{
    url: “(removed due to post link limits)”,
    startingRef: “Dev”
    }]
    }
    });

  4. Send a minimal prompt:

    await agent.send(“Reply OK”);

  5. Observe immediate failure (~300–1000ms):

    [validation_error] Failed to verify existence of branch ‘Dev’ in repository. Please ensure the branch name is correct.

  6. Repeat step 3–5 with startingRef “master” and “main” on the same repo → same error.

  7. (Optional UI repro) Open (removed due to post link limits), select Bitbucket repo triadicsoftware/taskmaster-api, and check whether branch dropdown lists Dev/master or fails similarly.

  8. (Proves branches exist outside Cursor) With a separate Atlassian API token (not passed to Cursor):
    GET (removed due to post link limits)
    GET (removed due to post link limits)
    → both return 200; branches exist on Bitbucket.

Expected Behavior

With Bitbucket Connected on the same Cursor account as the API key, Agent.create + send() with repos and startingRef “Dev” should verify the branch and start the Cloud VM.

At minimum, agents should list branches for repo (Dev, master).

Screenshots / Screen Recordings

Operating System

Other

Version Information

Reproduction path: Cloud Agent via @cursor/sdk (HTTP API), not Cursor IDE or CLI.

SDK:
@cursor/sdk ^1.0.5
Node.js v22.x

API:
GET (removed due to post link limits) → 200 OK
Agent.create + send() with cloud.repos + startingRef

Cloud runtime:
Bitbucket Cloud (bitbucket.org)
Workspace: triadicsoftware
Example repo: (removed due to post link limits)
startingRef: Dev (also fails for master, main)

Model: auto

Client OS not relevant — same validation_error from Linux production worker using the same API key and payload. Failure occurs server-side on send() branch verification before any Cloud VM boots.

Cursor IDE / CLI version: N/A (not used for reproduction)

For AI issues: which model did you use?

auto (model: { id: “auto” })

For AI issues: add Request ID with privacy disabled

N/A — failure occurs on send() before a meaningful agent run completes (validation_error on branch verify). No stable run ID to attach.

Additional Information

Related threads:

  • (removed due to post link limits)/cloud-agents-cant-get-branches-from-bitbucket-repo/169511
  • (removed due to post link limits)/validation-error-failed-to-verify-existence-of-branch-main-in-repository-foo-bar-repo-git-please-ensure-the-branch-name-is-correct/163842

Bitbucket REST (our separate Atlassian token, NOT passed to Cursor):
GET (removed due to post link limits)refs/branches/Dev → OK
GET (removed due to post link limits)refs/branches/master → OK

Cursor SDK payload:
repos: [{ url: “(removed due to post link limits)”, startingRef: “Dev” }]
skipReviewerRequest: true, autoCreatePR: false, workOnCurrentBranch: false

Repos are private; URL format is standard clone URL without /branch/Dev in the path.

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey @Derrick_Staggers, thanks for the detailed report. From the logs and screenshots, it’s clear you already checked everything.

This isn’t on your side. The Bitbucket connection and API key look fine, and the branches are correct everywhere except the branch-verification step that the Cloud Agents API runs when creating an agent. It looks like something changed in a recent release and affected this specific API/SDK path for Bitbucket Cloud repos, which is why it started failing today after about 2 weeks of working normally. I’ve sent this to the team and we’re tracking it. I’ll post an update right here as soon as I have one.

For now, a workaround is to start the agent via cursor.com/agents, then pick your Bitbucket repo and the Dev branch there. I know this isn’t a direct fix for your SDK tool, but it should keep you unblocked while we get the API path fixed.

Two quick clarifications:

  • Cursor.repositories.list() currently returns GitHub repos only, so getting 0 results for a Bitbucket-only account is expected and not related to this issue.
  • Follow-up messages to your existing agent on the Dev branch were failing for a separate reason, and we’re looking into that too.

Let me know if the web workaround doesn’t work.

Thanks for the confirmation.

Is their an ETA for fix? I’m trying to build this as a tool so it makes me nervous that if I had been using my tool for full development I would be down for over a full day now. Also all the tokens used in my local cursor trying to diagnose an issue they was unfixable by me feel bad to lose since I didn’t have many left.

Is their any kind of regression testing when they change the SDK? It feels like that should have flagged something if they made a breaking change.

I have been burning tokens on the same issue. My entire cloud agent workflow has been ground to a halt and using the web interface defeats the point of automation. ETA of a fix?

@Jon_Friedlander - yep, I’m seeing the same symptom on your side. It’s the same issue we’re tracking: the Cloud Agents API/SDK flow fails on the branch verification step for Bitbucket Cloud. Until it’s fixed, running via cursor.com/agents works (pick your Bitbucket repo and the branch you need) because the web flow isn’t affected. I know that’s not a replacement for automation, but it should keep you unblocked until the API path is fixed.

@Derrick_Staggers - I don’t have an exact ETA yet, and I don’t want to guess a date. The issue has been handed to the team and is being tracked, I’ll reply right here as soon as there’s an update.

About the tokens that were used for debugging: email [email protected] with your account details. That team handles usage questions and can look into your case.

I’ll pass the feedback about regression tests to the team. That’s a fair point, especially when you’re building tooling on top of an API.

Let me know if the web workaround doesn’t work anywhere.

So, I was able to get my automaton temporarily working but it’s not a great solution. I guess there are lots of things to fix but given this was broken due to a release, the fix would seemingly be easy to revert or corerct. I suppose the issue isn’t affecting enough people to push the issue high enough on the priority list as it’s been 60 hours and they have alreayd foudn and fixed several other production breaking issues.

It feels bad beacuse if I was building this to do my main source of development on, or even sell as a service to others then this would be killing my production really badly for several days. That’s not a good look. I understand bugs happen but since this was working, was broken by a Cursor release, confirmed to be a Cursor issue and it’s been 60 hours with no fix, it does feel like it’s not a high priority.

Obviously, none of that is directed at you Dean, I really apprecaite your time to reply and ready though this and help us flag the issue. I know there is only so much you can do to make the team aware. Thank you for helping us flag the issue and keeping us up to date.