Docs/UX: ENTRYPOINT vs CMD interaction unclear on Windows Docker Desktop (double-arg burn)

[chirag127]

Problem

When running a pre-built image whose Dockerfile uses ENTRYPOINT ["binary"] (exec form), Windows Docker Desktop users commonly pass what they think is "the command" as extra args and get confusing failures.

Concrete case burning our team this week: an upstream image sets ENTRYPOINT ["headroom"] (the binary), so the correct invocation is:

docker run --rm -p 8787:8787 ghcr.io/example/headroom:latest proxy

But the natural intuition on Windows (and what the Docker Desktop UI "Run" dialog nudges you toward when you type into the "Command" field) is:

docker run --rm -p 8787:8787 ghcr.io/example/headroom:latest headroom proxy

That silently becomes headroom headroom proxy — the binary sees headroom as its first positional arg and dies with a cryptic error, not an "unknown command: headroom" that would point at the mistake.

Why this is a Docker Desktop for Windows issue specifically

1. The Docker Desktop UI "Run" dialog has a "Command" field with placeholder text sh — heavily implies "type the full command including the binary here." No hint that this is CMD, appended to ENTRYPOINT.
2. docker inspect shows Entrypoint and Cmd as separate fields, but the Desktop UI does not surface Entrypoint at all on the Run dialog. Corp Windows users (locked down, no docker inspect habits) never see it.
3. PowerShell users are especially prone to this because PS quoting rules make docker run img "sub cmd" look identical to docker run img sub cmd in transcripts — the double-arg burn only shows up at runtime.

Ask

Either / both:

• In the Docker Desktop Run dialog on Windows: show the image's Entrypoint value (read-only) above the "Command" field, with a one-line hint: "Command is appended to Entrypoint as args."
• In the docs for docker run on Windows, add a short "ENTRYPOINT vs CMD" callout with the double-arg failure mode.

Currently the only place this is documented is the Dockerfile reference, which Windows Desktop users typically never read — they're driving the GUI.

Environment

• Docker Desktop 4.x on Windows 11 Enterprise
• WSL2 backend
• Corp environment (Defender + WSL constraints, so terminal-diagnosis is slow)

Happy to test a fix.