Bitbucket Git LFS Files Not Fetched in Pipelines

By Daniel Zoghalchali·Latchkey

By default Bitbucket clones do not fetch Git LFS objects, so LFS-tracked files arrive as small pointer files instead of real content. A build that reads them sees text pointers, not the asset.

What this error means

A binary or large asset tracked by LFS is tiny and unreadable in the build - its content is a version https://git-lfs... pointer. Enabling LFS during clone replaces the pointers with real files.

Bitbucket log

$ file assets/model.bin
assets/model.bin: ASCII text
$ head -1 assets/model.bin
version https://git-lfs.github.com/spec/v1

Common causes

LFS objects not pulled during clone

Bitbucket’s checkout does not fetch LFS content unless told to. LFS-tracked paths stay as pointer files, which break any tool that reads the real bytes.

LFS not enabled for the step

Even with LFS in the repo, the pipeline clone must opt in via clone: lfs: true (globally or per step) to materialize the objects.

How to fix it

Enable LFS on the clone

Set clone: lfs: true so the checkout pulls LFS objects.

bitbucket-pipelines.yml

clone:
  lfs: true

pipelines:
  default:
    - step:
        script: [ ./build-with-assets.sh ]

Or pull LFS explicitly in the step

bitbucket-pipelines.yml

script:
  - git lfs install
  - git lfs pull
  - ./build-with-assets.sh

How to prevent it

Set clone: lfs: true for pipelines that read LFS-tracked files.
Limit LFS pulls to steps that actually need the assets.
Verify LFS files are real content (not pointers) early while debugging.

Frequently asked questions

What causes "clone lfs"?