Git LFS "lfs.locksverify" locking not supported in CI

On push, LFS notices the remote advertises file locking and asks whether to verify locks. In CI, where nobody can answer, the push either warns repeatedly or fails; the fix is to set lfs.locksverify explicitly.

What this error means

A push prints "Locking support detected on remote \"origin\". Consider enabling it with: git config lfs.locksverify true" or fails when lock verification cannot be satisfied.

git-lfs

Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.locksverify true
Remote "origin" does not support the Git LFS locking API. Consider disabling it with:
  $ git config lfs.locksverify false

Common causes

Lock verification is left unset in CI

With lfs.locksverify unconfigured, LFS emits the advisory on every push, and a strict setting can block the push if it cannot verify locks.

The remote does not implement the locking API

When the server lacks lock support, verification requests have nothing to answer, producing the "does not support" variant.

How to fix it

Set locksverify explicitly

Decide whether the workflow uses LFS file locking.
Set git config lfs.locksverify true to enforce, or false to silence the advisory.
Commit the choice to .lfsconfig so every clone inherits it.

Terminal

git config lfs.locksverify false

Persist the setting in .lfsconfig

Store the decision in the repo so CI clones do not re-prompt on each push.

.lfsconfig

[lfs]
	locksverify = false

How to prevent it

Set lfs.locksverify explicitly for CI push jobs.
Commit the value in .lfsconfig for consistency.
Only enable locking when the team actually uses LFS locks.