4.86.0 (236216): shipped docker-wsl-cli.iso does not match its .sha256 sidecar — WSL bootstrap fails, engine never starts #587

Summary

On 4.86.0 (236216) the shipped resources/wsl/docker-wsl-cli.iso does not match the digest in its own resources/wsl/docker-wsl-cli.iso.sha256 sidecar. The WSL bootstrap verifies the pair on every start, fails, and the engine never comes up — Docker Desktop sits in "Starting the Docker Engine…" indefinitely.

[wsl-bootstrap][F] preparing environment: mounting cli-tools iso: copying to cache:
expected digest 9208137e0317e22ba33056954d36d90e50ca94b03449a1d5c4fa80b63e0f3e9d
actual digest   ea3d64ec2a1523c58d784cc6c45a08ba4c979302271a85dfc9f36eef88e5d613

9208137e… is the literal content of the sidecar file; ea3d64ec… is the SHA-256 of the ISO as written by the installer.

Environment

• Docker Desktop 4.86.0 (236216), WSL 2 backend, engine 29.7.2
• Windows 11 Pro, build 26200.8875 (25H2), fully patched
• Custom disk image location, containerd snapshotter enabled

Steps to reproduce

1. Install 4.86.0 from the full installer for build 236216 (Docker Desktop Installer.exe, Authenticode signature valid, CN=Docker Inc).
2. Start Docker Desktop.
3. Engine never starts; com.docker.backend.exe.log loops on the digest mismatch above.

What I verified

• Not a corrupted download or a broken delta update. First seen after a 4.83 → 4.86 delta update; reproduced afterwards on a full uninstall + clean install from the full installer.
• Not unstable I/O. Get-FileHash on the installed ISO returns the identical value on repeated runs, and Docker's own actual digest matches what I compute externally.
• Not failing storage. All physical disks report HealthStatus: Healthy; no disk/NTFS warnings or errors in the System event log.
• No third-party antivirus — Windows Defender only.
• The sidecar file is exactly 64 bytes, i.e. a bare hex digest, and it is the only place in the installation tree containing 9208137e….

Impact

Hard blocker: the engine cannot start at all. There is no in-product way to skip or refresh the check, and reinstalling reproduces it because the installer lays down the same pair.

Workaround

Write the ISO's actual digest into the sidecar (requires admin, since the path is under Program Files):

$iso     = "$env:ProgramFiles\Docker\Docker\resources\wsl\docker-wsl-cli.iso"
$actual  = (Get-FileHash -LiteralPath $iso -Algorithm SHA256).Hash.ToLower()
[System.IO.File]::WriteAllText("$iso.sha256", $actual, (New-Object System.Text.ASCIIEncoding))

After that the bootstrap passes and the engine starts normally. The workaround has to be re-applied after every Docker Desktop update, because the installer rewrites the sidecar.

Question

Is the sidecar generated from a different artifact than the ISO that ships in resources/wsl/ (for example the pre-compression or pre-signing version)? If so, the mismatch may affect every 4.86.0 installation where this code path runs, and the check is comparing against a digest the shipped file can never have.