Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,320 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@v-Kaniska244 y travaille déjà.

Depuis le 7/10/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

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

Langage dominant
TypeScript
Étoiles
3k
Forks
462
Merge moyen
13 h 28 min
PR mergées (30 j)
2

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de devcontainers/cli

Toutes les issues de devcontainers/cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.