Top-level `docker bake` ignores the selected builder (`docker buildx use`) — builds on the context's docker driver instead of the current docker-container builder

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem

Description

Given a docker-container builder selected as the current builder (via docker buildx create --use / docker buildx use), the top-level docker bake <target> builds on the active docker context's implicit docker-driver builder, while docker buildx bake <target> builds on the selected docker-container builder. The two commands pick different builders from identical state.

Expected behaviour

Both docker bake and docker buildx bake should build with the builder that is currently selected — the one marked * in docker buildx ls and recorded in ~/.docker/buildx/current. docker bake reports Usage: docker buildx bake in its --help, so the two are expected to resolve the builder identically.

Actual behaviour

With a docker-container builder selected as current (confirmed by docker buildx ls and ~/.docker/buildx/current), and a non-default docker context active:

• docker buildx bake app → #0 building with "repro-buildx" instance using docker-container driver ✅
• docker bake app → #0 building with "repro-ctx" instance using docker driver ❌ — falls back to the active context's implicit docker-driver builder, ignoring the selection.

This has real consequences: the docker-container driver supports cache exporters and features the docker driver does not, and tooling that acts on the selected builder (e.g. reproducible-containers/buildkit-cache-dance, which injects/extracts cache mounts against the selected builder) then silently operates on a different builder than the one docker bake actually used.

Buildx version

github.com/docker/buildx v0.35.0-desktop.2 b554ce1decd8b509893b1e7c6227eabfb923d094

Also reproduces on GitHub Actions with the upstream release github.com/docker/buildx v0.35.0 a319e5b15052cf6557ceb666eb8ff6e32380b782 (Docker 29.6.2, docker/setup-docker-action@v5 + docker/setup-buildx-action@v4).

Docker info

Client:  Docker 29.6.2, Context: desktop-linux, buildx v0.35.0-desktop.2
Server:
 Server Version: 29.6.2
 Storage Driver: overlayfs (io.containerd.snapshotter.v1)
 Cgroup Version: 2
 containerd version: e53c7c1516c3b2bff98eb76f1f4117477e6f4e66
 runc version: v1.3.6-0-g491b69ba
 Kernel Version: 6.12.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 10 / Total Memory: 7.65GiB
(plugin list, labels and local paths trimmed)

Builders list

Current builder is the docker-container instance (*), yet docker bake used the repro-ctx docker driver:

NAME/NODE        DRIVER/ENDPOINT      STATUS     BUILDKIT   PLATFORMS
repro-buildx*    docker-container
 \_ repro-buildx0  \_ repro-ctx         inactive
default          docker
 \_ default        \_ default           running    v0.31.2    linux/amd64 (+2), ...
desktop-linux    docker
 \_ desktop-linux  \_ desktop-linux     running    v0.31.2    linux/amd64 (+2), ...
repro-ctx        docker
 \_ repro-ctx      \_ repro-ctx         running    v0.31.2    linux/amd64 (+2), ...

$ cat ~/.docker/buildx/current
{"Key":"repro-ctx","Name":"repro-buildx","Global":false}

Configuration

Minimal reproduction (mirrors what docker/setup-docker-action — creates and uses a non-default context — and docker/setup-buildx-action --use do). The essential ingredients are a non-default active docker context plus a docker-container builder selected as current:

# Dockerfile
# syntax=docker/dockerfile:1
FROM alpine
RUN echo hello

# docker-bake.hcl
target "app" {
  dockerfile = "Dockerfile"
}

# create + use a non-default context pointing at the same daemon
$ docker context create repro-ctx --docker host="$(docker context inspect $(docker context show) --format '{{.Endpoints.docker.Host}}')"
$ docker context use repro-ctx

# create a docker-container builder and select it
$ docker buildx create --name repro-buildx --driver docker-container --use

$ cat ~/.docker/buildx/current
{"Key":"repro-ctx","Name":"repro-buildx","Global":false}   # docker-container builder is current

# same target, two commands, different builder:
$ docker bake app          # -> #0 building with "repro-ctx" instance using docker driver          (unexpected)
$ docker buildx bake app   # -> #0 building with "repro-buildx" instance using docker-container driver (expected)

Build logs

# docker bake app
#0 building with "repro-ctx" instance using docker driver

# docker buildx bake app
#0 building with "repro-buildx" instance using docker-container driver

Additional info

• ~/.docker/buildx/current correctly records the docker-container selection keyed to the active context, so docker buildx use / --use itself works — only the top-level docker bake entrypoint diverges.
• The trigger requires a non-default active docker context whose implicit default is the docker driver, plus a docker-container builder selected as current. With the default context active, both commands agree.
• Top-level docker bake --help prints Usage: docker buildx bake, so it appears to route through buildx; the divergence seems to be in how the top-level command entrypoint resolves the current builder vs. the docker buildx bake subcommand path. (If the top-level bake alias is registered/dispatched by docker/cli rather than buildx, this may need to be transferred there.)

Reproduce the mismatch with a non-default Docker context and a selected docker-container builder, comparing the top-level docker bake entry point with docker buildx bake. Then inspect how the CLI dispatches the top-level alias and how each path resolves the current builder. Done means both commands use the selected builder in this configuration, or the issue is transferred if dispatch belongs elsewhere.