Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,320 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@v-Kaniska244 arbeitet bereits daran.

Seit 07.10.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

@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.

Vorherrschende Sprache
TypeScript
Sterne
3k
Forks
462
Ø Merge
13 Std. 28 Min.
Gemergte PRs (30 T.)
2

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus devcontainers/cli

Alle Issues in devcontainers/cli

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.