One client controls containers, images, builds, and Swarm
Docker CLI is the familiar front end to Docker Engine. Its generated command reference covers container lifecycle, image transfer, BuildKit-backed builds, networks, volumes, contexts, registry login, and Swarm objects. The client can point at a local Unix socket or a remote daemon, with environment variables and flags controlling the host, API version, TLS certificates, and configuration directory. That breadth is why scripts often treat docker as the default container interface.
The binary is still a client. Commands such as run, pull, and inspect depend on an engine endpoint, while contexts decide which endpoint receives them. Configuration precedence is explicit: command-line options override environment variables, which override config.json. Teams switching among local, staging, and production daemons should use named contexts and inspect the active one, since a correct command sent to the wrong host can be more damaging than a syntax error.
Source development goes through Buildx bake targets
The root README says the repository is developed using Docker. Its standard commands are docker buildx bake for a source build, docker buildx bake cross for supported platforms, and bake targets for linting and tests. A Makefile path also exists for unit and full suites. This gives contributors repeatable containerized tooling, but it means the development setup depends on the product being built.
The repository itself is substantial: our checkout held 1,372 files and about 109,485 lines of source in 5.9 MB. We found 11 CI workflow files, which fits a project shipping across platforms and touching credentials, terminals, HTTP, plugins, and daemon APIs. There was no Dockerfile or tests directory in our scan. Tests are distributed through Go packages and bake definitions rather than gathered under a directory named tests.
What happened when we ran it
Our sandbox measured cmd/docker-trust at commit 45f5895, not the full CLI. Installing its Go module succeeded in 30 seconds and brought in 176 packages. The subproject built in 38 seconds inside an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and the golang:1.24-bookworm image.
The test step failed with exit code 1 after 26 seconds. Go reported 4 packages passed and 3 failed out of 7. The decisive line came from trust/revoke_test.go:160: undefined: test.TerminatePrompt. The trust package therefore failed during test compilation, while internal/registry and internal/trust logged successful results. The log does not establish why that symbol was unavailable, so blaming a Go version or dependency mismatch would be guesswork.
That outcome is narrower than saying Docker CLI's full test suite failed. We did not run the root bake test matrix, cross-build every platform, connect to a daemon, or exercise registry trust end to end. It is still actionable for someone changing cmd/docker-trust: the measured commit built its executable, but the available package test command did not produce a clean result in our stated environment.
Authentication has a daemon-less edge case
Docker's client can perform some registry login work when the daemon is unavailable. Open issue 7237 reports a specific flaw in that fallback: with a private registry using plain HTTP Basic Auth, a wrong password receives a 401 yet the CLI prints Login Succeeded and exits 0. The reporter says the same credentials fail correctly when the daemon is running. That report concerns one authentication path, not Docker Hub's usual bearer-token flow.
The safe operational rule is simple. Verify the daemon or selected context is reachable before diagnosing registry credentials, and confirm access with the operation you intend to perform. A success string from a fallback path should not be your only evidence. Configuration may contain registry credentials and client TLS keys, so permissions on the Docker config directory also matter.
Long-running terminal behavior still has open fixes
Issue 6005 reports 100 percent CPU use when docker run -i is placed in the shell background. A current pull request addresses the stdin handling. Issue 5299 says docker stack deploy --detach=false can wait forever when a one-shot service has completed successfully, and another active pull request proposes treating that task as converged. Both issues had activity in August 2026, which is better evidence of maintenance than an old tag.
GitHub recorded a push on August 27, 2026, and listed 874 open issues and pull requests combined. That queue is large because the CLI has a large surface and user base; it is not a count of confirmed bugs. The latest-release API returned no GitHub release, so release staleness cannot be judged from that endpoint. Current pushes and same-week issue work show that development is active.
Docker users should take the standard client; contributors need the full matrix
For operating Docker Engine, choosing this CLI is the least surprising option. It matches Docker's contexts, configuration, plugins, documentation, and daemon API conventions. Podman or nerdctl make more sense when the underlying engine is different or daemonless operation is the goal.
Source contributors face a higher bar than the 38-second trust build suggests. The project spans 109,485 source lines and 11 workflow files, and our focused tests found a compile failure that the build did not catch. Run the relevant package tests, then the prescribed bake targets for the affected platform and behavior. For cmd/docker-trust at commit 45f5895, the undefined test helper must be resolved before calling that subproject clean.