Description
Running a Compose project distributed as an OCI artifact fails during the client-side OCI fetch with a proxy error referencing a named pipe (./pipe/dockerHttpProxy) that cannot be found. A normal daemon-side docker pull against the same registry (Docker Hub) works fine, so general registry connectivity is healthy — the failure is specific to the Compose CLI's own OCI fetch.
Steps to reproduce
-
On Windows with Docker Desktop running, run any Compose project published as an OCI artifact. I've created this as an easy reproducible OCI artifact:
docker compose -f oci://docker.io/cruizba/nginx-oci-example-compose:latest up -d
Expected behavior
Compose fetches the OCI artifact from Docker Hub and brings the project up.
Actual behavior
The command fails immediately at the OCI fetch step:
level=info msg="fetch failed" error="failed to do request: Head \"https://registry-1.docker.io/v2/cruizba/nginx-oci-example-compose/manifests/latest\": proxyconnect tcp: open ./pipe/dockerHttpProxy: The system cannot find the path specified." host=registry-1.docker.io
failed to pull OCI resource "docker.io/cruizba/nginx-oci-example-compose:latest": failed to do request: Head "https://registry-1.docker.io/v2/cruizba/nginx-oci-example-compose/manifests/latest": proxyconnect tcp: open ./pipe/dockerHttpProxy: The system cannot find the path specified.
Additional context
- A daemon-side pull from the same registry works without issue:
docker pull hello-world:latest # succeeds
This indicates the daemon's networking/proxy path is fine; only the Compose CLI's client-side OCI fetch is affected.
- The client-side OCI fetch appears to pick up an HTTP proxy configuration pointing at the Docker Desktop named pipe
./pipe/dockerHttpProxy, which it cannot resolve from the native Windows process context.
Platform
- Docker Desktop: 4.77.0 (228796)
- Docker Engine: 29.5.3 (API 1.54)
- Docker Compose: v5.1.4
- OS: Windows 11 Home, build 10.0.26200
Version information
Client:
Version: 29.5.3
API version: 1.54
Go version: go1.26.4
Git commit: d1c06ef
Built: Wed Jun 3 18:03:06 2026
OS/Arch: windows/amd64
Context: desktop-linux
Server: Docker Desktop 4.77.0 (228796)
Engine:
Version: 29.5.3
API version: 1.54 (minimum version 1.40)
Go version: go1.26.4
Git commit: 285b471
Built: Wed Jun 3 17:59:56 2026
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.4
runc:
Version: 1.3.5
docker-init:
Version: 0.19.0
Diagnostics ID
No response
Note
Sorry for the duplicated issue, I though I posted it in the wrong repo
Description
Running a Compose project distributed as an OCI artifact fails during the client-side OCI fetch with a proxy error referencing a named pipe (
./pipe/dockerHttpProxy) that cannot be found. A normal daemon-sidedocker pullagainst the same registry (Docker Hub) works fine, so general registry connectivity is healthy — the failure is specific to the Compose CLI's own OCI fetch.Steps to reproduce
On Windows with Docker Desktop running, run any Compose project published as an OCI artifact. I've created this as an easy reproducible OCI artifact:
Expected behavior
Compose fetches the OCI artifact from Docker Hub and brings the project up.
Actual behavior
The command fails immediately at the OCI fetch step:
Additional context
./pipe/dockerHttpProxy, which it cannot resolve from the native Windows process context.Platform
Version information
Client: Version: 29.5.3 API version: 1.54 Go version: go1.26.4 Git commit: d1c06ef Built: Wed Jun 3 18:03:06 2026 OS/Arch: windows/amd64 Context: desktop-linux Server: Docker Desktop 4.77.0 (228796) Engine: Version: 29.5.3 API version: 1.54 (minimum version 1.40) Go version: go1.26.4 Git commit: 285b471 Built: Wed Jun 3 17:59:56 2026 OS/Arch: linux/amd64 Experimental: false containerd: Version: v2.2.4 runc: Version: 1.3.5 docker-init: Version: 0.19.0Diagnostics ID
No response
Note
Sorry for the duplicated issue, I though I posted it in the wrong repo