fix(publish): bypass Docker Desktop proxy for loopback registries

[ptrdom]

What I did

docker compose publish routed all registry traffic through Docker Desktop's HTTP proxy. Publishing to a registry on localhost therefore failed on Windows with:

proxyconnect tcp: open ./pipe/dockerHttpProxy: The system cannot find the path specified.

even though docker push/docker pull worked against the same registry.

Two bugs in internal/desktop/proxy.go:

1. No loopback bypass. ProxyTransport forced every request through the DD proxy and its DialContext always dialed the proxy socket, so loopback targets could never connect directly. Proxy selection now bypasses the proxy only for loopback targets (localhost, 127.0.0.0/8, ::1); all other registry traffic stays routed through Docker Desktop's PAC-aware proxy, so Desktop keeps ownership of proxy decisions (e.g. enterprise-managed proxies). The local process NO_PROXY/no_proxy is deliberately not honored, so a broad value such as * or .corp cannot bypass centrally managed proxy policy. DialContext routes only the sentinel proxy address to the DD socket and dials loopback targets directly.
2. Malformed Windows pipe path. The proxy named-pipe endpoint was hardcoded as npipe://./pipe/..., yielding the relative path ./pipe/dockerHttpProxy. It is now derived from the engine endpoint, preserving its namespace. Docker Desktop reports the endpoint in the backslash form npipe://\\.\pipe\docker_cli, so the derivation uses LastIndexAny to handle both backslash and forward-slash forms.

Result: publishing to localhost:5000 connects directly like docker push, while every non-loopback registry still goes through the Docker Desktop proxy (now reachable on Windows).

Related issue

Fixes #13824

How I tested

Validated end-to-end on Docker Desktop 29.5 / Windows 11 (the issue's environment) by building binaries from both the parent commit and this branch and running the issue's reproduction steps:

# start a plain-HTTP localhost registry
docker run -d -p 5000:5000 --name registry registry:3

# minimal compose.yaml referencing any pushable image, then publish
# (spike-app is the placeholder image name from #13824's repro steps;
#  --insecure-registry tells the OCI resolver to use plain HTTP)
docker compose publish localhost:5000/spike-app:1 --insecure-registry -y

• Parent commit: reproduces the issue verbatim — proxyconnect tcp: open ./pipe/dockerHttpProxy: The system cannot find the path specified. (exit 1).
• This branch: publishes successfully (exit 0); the artifact lands in the localhost registry.

Automated coverage in internal/desktop/proxy_test.go:

• TestDDProxyFunc_BypassesLoopbackOnly — loopback names/IPs bypass the proxy; all other hosts (including ones a local NO_PROXY would match) stay routed through Docker Desktop.
• TestHTTPProxySocketEndpoint_WindowsNamedPipe — proxy pipe path keeps the engine endpoint's namespace for both backslash and forward-slash forms.

---

🤖 Generated with Claude Code

[ptrdom]

I have also manually tested this on MacOS (M1 Mac) with Docker Desktop, managed to reproduce the issue and confirmed that this PR fixes it.

[glours]

Hello @ptrdom
Thanks for this contribution.

I’m concerned about the NO_PROXY part of this change.

The loopback bypass makes sense and seems like the right fix for the localhost registry case. However, this PR also makes the Compose OCI transport honor the local process NO_PROXY / no_proxy environment before routing through Docker Desktop’s proxy.

That changes the behavior introduced in 66c21c3, where OCI traffic was routed through Docker Desktop’s PAC-aware proxy so Desktop can own proxy decisions, especially for enterprise environments with managed or non-standard proxy configurations.

With this change, a broad local NO_PROXY value such as *, .corp, or a specific internal registry host could bypass Docker Desktop’s proxy entirely and connect directly. That could break enterprise proxy setups or bypass centrally managed proxy policy.

Can we keep the direct bypass limited to loopback targets only, and continue routing all other OCI registry traffic through Docker Desktop’s proxy?

[Copilot]

Pull request overview

This pull request fixes docker compose publish failures on Docker Desktop/Windows when targeting localhost or insecure registries by ensuring loopback/NO_PROXY destinations bypass Docker Desktop’s HTTP proxy and by correctly deriving the Windows named-pipe proxy endpoint.

Changes:

• Update the Docker Desktop proxy transport to use httpproxy.Config.ProxyFunc for loopback/NO_PROXY bypass and to only dial the Desktop proxy socket for proxied requests.
• Fix Windows named-pipe proxy endpoint derivation to preserve the engine endpoint namespace (supports both backslash and forward-slash forms).
• Add/adjust unit tests covering loopback + NO_PROXY proxy selection and Windows named-pipe endpoint derivation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
internal/desktop/proxy.go	Implements loopback/NO_PROXY bypass and correct proxy socket dialing logic; fixes Windows pipe endpoint derivation.
internal/desktop/proxy_test.go	Adds tests for proxy bypass behavior and Windows named-pipe endpoint derivation.
go.mod	Adds golang.org/x/net for httpproxy usage (can be avoided by using the stdlib package).

[codecov]

Codecov Report

❌ Patch coverage is 70.83333% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/desktop/proxy.go	70.83%	5 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[ptrdom]

@glours Thank you for a prompt review, I think your concern makes sense, I have pushed changes to address it.

[glours]

I don’t see a blocker in the code after this update. One thing I’d still like to adjust before merging is the PR description/title: they still mention insecure registries broadly and the body still says NO_PROXY is honored, which is no longer the intended behavior. Could you update the wording to make it clear that only loopback targets bypass the Desktop proxy, while all other registry traffic stays routed through Docker Desktop?

[ptrdom]

Makes sense, updated, let me know if any further tweaks are needed.