Lesstep
Bitbucket Cloud · Pipelines · Checked October 29, 2026

Bitbucket Pipelines: "We couldn't clone the repository. Try rerunning the pipeline."

The step fails before its script starts. At the start of every step, Pipelines clones your repository, and this message only says that the clone failed. Open the failed step's log and expand Build setup: Git's reason is there, usually a line starting with fatal:. That is what an Atlassian support engineer asks for first in a community thread about this message, adding that the cause cannot be told without it. Build setup runs git clone --branch=<branch> --depth 50 and then git reset --hard to the build's commit; build logs posted in the community also show it retrying the clone, with lines like Attempt 1 of 6 failed. Running the pipeline again helps only when the cause has passed.

"already exists and is not an empty directory"

fatal: destination path
'…/temp/<runner UUID>/build'
already exists and is not an
empty directory.

This happens on a self-hosted Linux shell, macOS or Windows runner. Those run directly on the host, so the build folder is a real folder there, and files from an earlier build were left in it. A line in the step's script cannot clean it: the step fails before the script runs. On the host, following Atlassian's article (Pipeline build failed with We couldn't clone the repository): stop the runner, delete the build folder inside each <runner UUID> folder of the runner's working directory (by default atlassian-bitbucket-pipelines-runner/temp/), and start the runner again. The same article names three more causes on self-hosted runners: a host that lacks the runner's prerequisites, more than one instance of the runner on the same machine, and a runner without permission on the folder it clones into. On Windows, PowerShell must be allowed to run unsigned scripts.

"mkfifo: …/tmp/clone_result: File exists"

The runner could not clean up after the step it ran before. At the end of each step a runner deletes the build directories; when it can't, because of a file's permissions or a program still using a file, it goes Unhealthy (A runner is in an unhealthy state and cannot run pipelines), and the steps after that fail on it. Look at the Build teardown section of the previous step on that runner, and at the end of runner.log in <working directory>/<runner UUID>/ for An error occurred whilst tearing down directories. In the thread with this line, removing the file or restarting the machine cleared it. If you changed a Linux Docker runner's working directory, Atlassian's engineer adds, the volume must be mounted at the same path on both sides:

docker run … \
  -v /mydir:/mydir \
  -e WORKING_DIRECTORY=/mydir …

"Could not resolve host: bitbucket.org"

fatal: unable to access '…':
Could not resolve host: bitbucket.org

The machine the step runs on could not look up bitbucket.org. On a self-hosted runner, Atlassian's engineer points to DNS first and then the firewall: allow the addresses in IP addresses for runners behind corporate firewalls. Atlassian publishes them at ip-ranges.atlassian.com and says they can change, so allow by that list rather than by addresses copied once.

Behind a proxy that signs with its own certificate, the line is SSL certificate problem: self signed certificate in certificate chain instead. For a step on a self-hosted runner, Atlassian's Git clone behavior has an option that turns off certificate checks for the clone:

- step:
    runs-on:
      - self.hosted
    clone:
      skip-ssl-verify: true

"Could not parse object": the clone is too shallow

By default the clone takes the last 50 commits of the branch (Git clone behavior). When the build's commit is not among them, git reset --hard cannot find it. Atlassian's engineer lists this among the causes, and Atlassian's article on the related message, "The commit could not be found in the cloned repository", names two ways in: running a build again more than 50 commits later, and a force push that replaced the commit. For the first, clone the whole history:

clone:
  depth: full

With Git 2.53 on a local copy, a --depth 50 clone could reset to a commit 10 back, and for one 55 back it stopped at fatal: Could not parse object '…'. A commit that a force push removed cannot be built again unless someone pushes it back.

On Atlassian's own machines

When the step ran on Bitbucket's machines and Build setup shows no clear reason, look at status.bitbucket.org. In a 2018 incident, Atlassian wrote that builds that failed during cloning were not charged and could simply be run again. Atlassian's engineer also lists a remote repository with broken tree entries. If it keeps failing, Atlassian's support can read the build logs; in the community, its engineer asks for a ticket from a workspace on a paid plan.

See Build setup's reason from IntelliJ IDEA

Pipeline Inbox for Bitbucket Pipelines, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of all your Bitbucket Cloud repositories in an IDE tool window. For a failed pipeline it shows the command the step stopped at and its error lines: when the clone fails, that is Build setup's git clone and Git's fatal: line, without opening the log. After you clean up the runner there is no new commit to push: with Pro, Run again builds the same commit once more from the IDE (for a commit more than 50 commits behind its branch, set depth: full first). The list, steps and logs are free; running, re-running and stopping pipelines are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

Atlassian, Bitbucket and Bitbucket Pipelines are trademarks of Atlassian; Git is a trademark of Software Freedom Conservancy; Docker is a trademark of Docker, Inc.; Windows and PowerShell are trademarks of the Microsoft group of companies; macOS is a trademark of Apple Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by any of them.

More: Submodules not cloned · "command not found" · "unexpected system error" · The cache is not used · Pipelines did not run after a push · "Exceeded build time limit of 120 minutes" · "Container 'Build' exceeded memory limit." · "Container 'docker' exceeded memory limit." · "No online runner available" · "No space left on device" · "Step exceeded processing limits" · The artifact is missing in the next step · The build passed before and fails now · Build setup takes too long · "You've run out of build minutes" · "Permission denied to update branch" · "You have reached your pull rate limit" (Docker Hub) · "There is an error in your bitbucket-pipelines.yml" · "This pipeline was paused" (deployments) · Bitbucket Pipelines plugins for IntelliJ IDEA, compared · 日本語