Build with setup-buildx-action@v4 + bake-action@v7 uses remote git context -> Git LFS pointer files in build context

Environment

• Repository using workflow: https://github.com/zeckson/mykapitel.ru (workflow path: .github/workflows/smoke-test.yml)
• GitHub Actions run: https://github.com/zeckson/mykapitel.ru/actions/runs/30447565481
• Workflow uses: actions/checkout@v6 (with lfs: true), docker/setup-buildx-action@v4, docker/bake-action@v7
• Works with older actions: setup-buildx-action@v3 + bake-action@v5

What happens

• When building with setup-buildx-action@v4 + bake-action@v7 and a build context that points to a subdirectory (./docker) containing a Git LFS-tracked file (docker/akeeba-backup.zip), BuildKit resolves that context as a remote git checkout and does not apply Git LFS smudge filters.
• The file seen inside the build context is a Git LFS pointer (contains the text "version https://git-lfs.github.com/spec/v1"), and the Dockerfile in this project intentionally rejects pointer files, causing the build to fail.

Failure log excerpt

• Error: akeeba-backup.zip is a Git LFS pointer, not the actual file.
• Dockerfile lines involved:
  COPY docker/akeeba-backup.zip /tmp/backup.zip
  RUN if grep -q "version https://git-lfs.github.com/spec/v1" /tmp/backup.zip; then echo "Error: akeeba-backup.zip is a Git LFS pointer, not the actual file." && exit 1; fi && unzip -t /tmp/backup.zip && unzip /tmp/backup.zip -d /app && rm /tmp/backup.zip

Reproduction steps

1. actions/checkout@v6 with lfs: true is used in the workflow so the runner workspace contains the smudged LFS file after checkout and (optionally) git lfs pull.
2. The workflow then sets up buildx using docker/setup-buildx-action@v4 and invokes docker/bake-action@v7 with a context set to the docker/ subdirectory (or similar subdir context).
3. BuildKit/bake resolves the subdirectory context via a remote git fetch which returns raw pointer file(s) and the build fails when the Dockerfile detects the pointer.

Expected

• When the runner workspace already has LFS objects checked out (actions/checkout + git lfs pull), bake/buildx should be able to use the smudged local files when the workflow requests a local workspace context, or at minimum there should be a clear way to force local context usage so builds don’t inadvertently use remote git checkouts that skip smudge filters.
• Behavior observed with setup-buildx@v3 + bake-action@v5: build used local workspace context (or LFS smudged files) and succeeded.

Notes and suggestions

• This appears to be related to how bake/buildx resolves subdirectory contexts — resolving them as remote git contexts causes LFS smudge filters to be bypassed, exposing pointer files to the build.
• Possible mitigation in workflows: explicitly force bake to use the local workspace context (e.g. *.context=./) and ensure git lfs pull runs on the runner before bake. But the action should either document this nuance or provide an option to prefer the runner workspace/local context when available.

Attachments / additional info

• Full failing run: https://github.com/zeckson/mykapitel.ru/actions/runs/30447565481 (logs are attached to that run)

Please let me know if you want me to open a minimal repro PR; I can also provide the exact workflow file and Dockerfile used in the failing run.

Start with .github/workflows/smoke-test.yml and compare the setup-buildx-action@v3/bake-action@v5 and @v4/@v7 configurations, especially the subdirectory context. Review the Dockerfile lines that copy and validate docker/akeeba-backup.zip, then reproduce with actions/checkout@v6 and Git LFS enabled. Done means the local-context behavior is corrected or clearly documented and the build no longer receives an LFS pointer.