Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,320 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@v-Kaniska244 ya está trabajando en esto.

Desde el 7/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
3k
Forks
462
Merge medio
13 h 28 min
PR fusionados (30 d)
2

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de devcontainers/cli

Todos los issues de devcontainers/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.