B_Lee
June 19, 2026, 2:52pm
1
docker compose -p openvidu-meet -f oci://openvidu/local-meet:latest up -y openvidu-meet-inithttps://registry-1.docker.io/v2/openvidu/local-meet/manifests/latest\ ”: proxyconnect tcp: open ./pipe/dockerHttpProxy: The system cannot find the path specified.” host=registry-1.docker.io spanID=9af306fef23c74a4 traceID=4ad1ec8d337ae9124951ceeb53936d49
Help as the Docker instructions are “Broked”
Thank you
Yep, there’s an issue with Docker Desktop:
opened 09:53AM - 22 Jun 26 UTC
kind/bug
### 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
1. 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
```bash
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
The easiest workaround is to use the Local Deployment from OpenVidu Platform.
Simply follow those instructions and OpenVidu Meet should work perfectly on your dev machine.
I suppose this will eventually be fixed in Docker Desktop.
1 Like