`devcontainer build` fails on Buildx 0.37.2 because the generated Dockerfile is outside the Compose bake context

@devcontainers/cli 0.89.0 fails devcontainer build for a Compose-based config on Buildx 0.37.2. The build exits in about one second, before any image layer, with:

additional privileges requested: pass "--allow=fs.read=/tmp/devcontainercli-runner/container-features/0.89.0-<id>/Dockerfile-with-features" to grant requested privileges

The same CLI, the same config, and the same generated override succeed on Buildx 0.37.1. That run gets as far as load build definition from Dockerfile-with-features.

Environment

Piece	Failing run	Succeeding run
@devcontainers/cli	0.89.0	0.89.0
Buildx	v0.37.2 (2d379c0c3f22da0d2759d132a0ec81ca949098f0)	v0.37.1 (0b265a9f62db554fa9aba6dd19e1bd5704bc7d8a)
Docker Compose	v2.38.2	v2.38.2
Docker Engine	28.0.4	28.0.4
Runner image	ubuntu24/20261004.327	ubuntu24/20260927.320
Node.js	v22.23.3	v22.23.3

Both runs used docker/setup-buildx-action@v4 with the docker-container driver. The driver was not the difference. The repository is private, so the log excerpt below is the part that can be read without that Actions run.

What the CLI ran

devcontainer.json has no features. The Compose service sets image and has no build key. The CLI still printed this override:

services:
  dev:
    image: vsc-<folder-hash>
    build:
      dockerfile: /tmp/devcontainercli-runner/container-features/0.89.0-<id>/Dockerfile-with-features
      context: /tmp/devcontainercli-runner/empty-folder
      args:
        - BUILDKIT_INLINE_CACHE=1
        - _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label

It then ran:

docker compose --project-name <project>_devcontainer \
  -f <workspace>/.devcontainer/compose.yaml \
  -f /tmp/devcontainercli-runner/docker-compose/docker-compose.devcontainer.build-<id>.yml \
  build <service>

Bake stopped at load local bake definitions. The exception is thrown from dist/spec-node/devContainersSpecCLI.js.

Reduced repro

Buildx v0.37.2 or newer, Compose v2.38.2, and @devcontainers/[email protected].

.devcontainer/devcontainer.json:

{
  "name": "bake-entitlement-repro",
  "dockerComposeFile": "compose.yaml",
  "service": "app",
  "workspaceFolder": "/workspace"
}

.devcontainer/compose.yaml:

services:
  app:
    image: mcr.microsoft.com/devcontainers/base:ubuntu
    command: sleep infinity

npm install -g @devcontainers/[email protected]
docker buildx version
devcontainer build --workspace-folder .

Expected: the build loads Dockerfile-with-features and continues, as it did on Buildx 0.37.1.

Actual on Buildx 0.37.2: exit 1 with additional privileges requested for that Dockerfile.

devcontainer build is the command that hits this with no features configured. In src/spec-node/devContainersSpecCLI.ts it calls buildAndExtendDockerCompose with canAddLabelsToContainer set to false. With no features, getExtendImageBuildInfo still returns featureBuildInfo in that case (src/spec-node/containerFeatures.ts). devcontainer up passes true and, for an image-only service with no features, can attach labels without writing that Dockerfile. up still hits the same override when features are configured, or when the service already has a Dockerfile.

Why Buildx 0.37.2 rejects it

Buildx v0.37.2 changed bake so --progress=rawjson rejects ungranted entitlements instead of skipping the consent check (GHSA-gwr2-q96m-6682). On a non-interactive run, bake returns the additional privileges requested error (bake/entitlements.go).

Compose v2.38.2 always invokes bake as bake --file - --progress rawjson (pkg/compose/build_bake.go). For Buildx 0.17.0 and newer it also passes --allow fs.read=<path>, but only for build.context and additional contexts. It does not pass the Dockerfile directory.

The CLI creates that split in src/spec-node/dockerCompose.ts. It writes Dockerfile-with-features under the features temp folder, then, when the service has no build context, sets context to empty-folder:

const finalDockerfilePath = cliHost.path.join(featureBuildInfo?.dstFolder, 'Dockerfile-with-features');
await cliHost.writeFile(finalDockerfilePath, Buffer.from(finalDockerfileContent));
buildOverrideContent += `      dockerfile: ${finalDockerfilePath}\n`;
// ...
if (!serviceInfo.build?.context) {
    const emptyDir = getEmptyContextFolder(common);
    await cliHost.mkdirp(emptyDir);
    buildOverrideContent += `      context: ${emptyDir}\n`;
}

When the service already has a context, the Dockerfile path is still that absolute features path, outside the context Compose entitles.

docker compose build has no --allow flag, and the CLI does not invoke docker buildx bake itself, so the required fs.read grant is never sent.

Workaround

BUILDX_BAKE_ENTITLEMENTS_FS=0 disables the filesystem check when no other entitlement is missing. That turns the check off for every path, not just this Dockerfile. Pinning Buildx 0.37.1 keeps the rawjson consent skip that 0.37.2 closed.

Suggested fix

Write Dockerfile-with-features inside the context directory Compose already entitles, and reference it with a path under that context. For an image-only service, the features temp folder can be that context, with a relative Dockerfile name. The empty-folder context plus an absolute Dockerfile outside it is the combination Buildx 0.37.2 refuses.

A Compose change that also entitles the Dockerfile directory would help every docker compose build that uses an absolute Dockerfile outside the context. The CLI override is what produces that shape for devcontainer build.