Docker "failed to solve: invalid file request" in CI

By Kaveh Alemi·Latchkey

BuildKit rejected a requested path as invalid. The path referenced by a COPY/ADD, or by -f, points outside the build context or to a location BuildKit will not serve, so the request is refused before the file is read.

What this error means

A build fails with failed to solve: invalid file request <path>, naming a file or directory a step asked for. The path is typically outside the context (a ../ escape) or otherwise unreachable.

docker

ERROR: failed to solve: invalid file request ../shared/config.json
# a COPY tried to reach above the build context root

Diagnose it: build context, cache, or platform?

A Dockerfile that builds locally and fails in CI usually differs in one of three ways: the build context contains different files, the layer cache is cold or poisoned, or the runner architecture does not match what the base image provides.

Terminal

# what is actually being sent as build context (dockerignore applies)
docker build --no-cache --progress=plain -t probe . 2>&1 | head -40

# what platform are you on, and what does the base image support?
docker version --format '{{.Server.Arch}}'
docker buildx imagetools inspect <base-image> | grep -i platform

# prove it is not a cache artefact
docker build --no-cache .

Common causes

A COPY/ADD escapes the build context

Source paths in COPY/ADD must live inside the context sent to the builder. A ../ that climbs above the context root is an invalid file request.

The -f Dockerfile sits outside the context

When the Dockerfile path resolves outside the build context, BuildKit cannot serve it as a context file and rejects the request.

How to fix it

Keep COPY sources inside the context

Move the needed files under the context, or widen the context to include them.

Terminal / Dockerfile

# instead of COPY ../shared/config.json .
# broaden the context so the file is inside it:
docker build -f service/Dockerfile -t myorg/api:1.4.2 .
# and reference it relative to the context root:
# COPY shared/config.json ./config.json

Use a named additional context for outside files

buildx can mount extra contexts so you do not need ../ escapes.

Terminal

docker buildx build \
  --build-context shared=../shared \
  -t myorg/api:1.4.2 .
# then in the Dockerfile:
# COPY --from=shared config.json ./config.json

Keep the build context small and deterministic

A missing .dockerignore sends node_modules, .git, and build output to the daemon, which is slow and can change layer hashes between environments.
A COPY of a path that exists locally but is gitignored will fail in CI, because the runner only has what the checkout produced.
Multi-arch builds need buildx and QEMU set up explicitly; a plain docker build on an ARM runner silently produces an ARM image.

How to prevent it

Keep all COPY/ADD sources inside the build context.
Use --build-context name=path instead of ../ escapes.
Set the context root so it contains every file the build needs.

Frequently asked questions

What causes Docker "failed to solve: invalid file request" in CI?

There are 2 common causes: a copy/add escapes the build context and the -f dockerfile sits outside the context. Source paths in COPY/ADD must live inside the context sent to the builder.

How do I fix Docker "failed to solve: invalid file request" in CI?

There are 2 fixes depending on which cause you have: keep copy sources inside the context and use a named additional context for outside files. Work through them in order, since the first is the most common.

What does Docker "failed to solve: invalid file request" in CI actually mean?

A build fails with failed to solve: invalid file request <path>, naming a file or directory a step asked for.

How do I stop Docker "failed to solve: invalid file request" in CI happening again?

Keep all COPY/ADD sources inside the build context. The prevention section lists 3 changes that keep it from recurring.