Docker Desktop 4.94: Safer Logs and Reliability Fixes

Docker Desktop 4.94 is now available with a safer logging default for new Linux containers, fixes for exposed API keys in diagnostics, more reliable startup and shutdown behavior, and platform-specific repairs for Linux, Windows, and macOS. The update also bundles Docker Engine 29.8.2, containerd 2.3.6, Buildx 0.37.2, and NVIDIA Container Toolkit 1.20.1.

For most developers, this is a worthwhile maintenance update rather than a release that changes daily Docker commands. The most practical changes are automatic rotation for newly created container logs, protection against sensitive API keys appearing in diagnostic bundles, and fixes for several frustrating reliability problems.

Key takeaways

• New Linux containers use Docker’s local logging driver by default in Docker Desktop, helping control log-file growth.
• Docker fixed cases where stored API keys and unobfuscated IPC values could appear in logs or diagnostic bundles.
• Linux users get a fix for Docker Desktop closing unrelated applications and terminal windows when quitting.
• Windows users get clearer WSL startup errors and a fix for a WSL automount timeout introduced in version 4.92.0.
• Docker Desktop 4.94 is rolling out gradually, so the update may not appear for every user immediately.

In this article

• What changed in Docker Desktop 4.94?
• Why the new logging default matters
• Security and diagnostics improvements
• Linux, Windows, and macOS fixes
• Updated Docker components
• Should you update now?
• How to update safely
• Frequently asked questions

What changed in Docker Desktop 4.94?

Docker published version 4.94 on October 5, 2026. The release is available for Windows, macOS, and Linux packages in Debian, RPM, and Arch formats. Docker notes that Desktop releases are rolled out gradually, which means some users may need to wait before the in-app updater offers it.

The release also fixes a shutdown deadlock, incorrect reclaimable-space reporting, invalid-settings error messages, and a case where the Docker Desktop service remained stopped after an update.

Why does the new logging default matter?

Docker Desktop 4.94 changes the default logging driver for new Linux containers to local. Docker says this enables automatic log rotation and reduces disk usage.

This addresses a common local-development problem: a noisy container can keep writing logs until its files consume a surprising amount of disk space. The local driver is designed for efficient local storage and rotates logs by default.

There are two limits to understand. First, the release notes describe the change for new Linux containers, so you should not assume existing containers were silently recreated with a different driver. Second, a Compose file or docker run command that explicitly sets another logging driver should continue to follow that configuration.

You can check the driver used by a container with:

docker inspect -f '{{.HostConfig.LogConfig.Type}}' CONTAINER_NAME

For a broader command reference, see our Docker command-line guide.

What security and diagnostics problems were fixed?

The most important privacy-related repair is that Docker Desktop no longer writes stored API keys in clear form to affected logs and diagnostic bundles. Docker also stopped logs from recording unobfuscated IPC payload values when those values are JSON arrays or plain strings.

That matters because diagnostic bundles are often attached to support tickets or shared between team members. They should still be treated as potentially sensitive files, but removing known secret-leak paths lowers the risk of accidental exposure.

Our practical recommendation is simple: update first, continue reviewing diagnostic bundles before sharing them, and rotate a credential if you know it appeared in an older bundle. The release notes do not say that every type of secret in every log is automatically redacted.

Which Linux, Windows, and macOS fixes stand out?

Linux

Docker fixed a Linux bug where quitting Docker Desktop could close unrelated applications, including open terminal windows. That is a high-impact usability fix for developers who keep multiple shells, editors, or monitoring tools open during a session.

Windows and WSL

Windows users now receive more useful WSL startup messages when virtualization is disabled in firmware, nested virtualization is unavailable, or the Windows hypervisor is disabled. Version 4.94 also fixes the WSL integration timeout while waiting for a distribution to be automounted, a regression introduced in Docker Desktop 4.92.0.

macOS

On Mac, the update fixes repeated privileged-access prompts after reboot, a CLI installation setting that could revert unexpectedly, zsh completion setup when ~/.zshrc did not exist, and a misleading update tooltip involving the /Applications folder.

Which components are updated?

Component upgrades can matter even when the Desktop interface looks unchanged. Build behavior, runtime compatibility, image analysis, and GPU-container support depend on the versions packaged underneath the application. Teams should still test their own Compose projects, build pipelines, bind mounts, networking, and local Kubernetes workloads instead of treating a successful application launch as complete validation.

If you are learning the image workflow, our guides explain how to build a Docker image and how to push an image to Docker Hub.

Should you update to Docker Desktop 4.94 now?

Most individual developers should update after saving important work and confirming that they can recreate their development environment. The diagnostics fixes, safer logging default, Linux quit repair, and WSL reliability work make 4.94 more useful than a routine component bump.

Teams with managed fleets should test the release on a small group first. Pay special attention to scripts or monitoring that assume a particular logging driver, local Kubernetes setups using kubeadm, GPU development environments, and machines controlled by administrator policies.

Our assessment: Docker Desktop 4.94 is a reliability-and-safety update with several fixes that users can feel immediately. It is worth installing, but the new logging default should be understood rather than treated as an invisible implementation detail.

How to update Docker Desktop safely

1. Commit or back up application files that are not already stored safely.
2. Record any important containers, volumes, Compose projects, and custom settings.
3. Stop workloads that should not be interrupted.
4. Install the update through Docker Desktop or the official download for your operating system.
5. Restart Docker Desktop and confirm the version in the application.
6. Run docker version, docker info, and a known project test.
7. Check container logs, networking, bind mounts, volumes, and local Kubernetes before resuming normal work.

Do not delete containers or volumes merely to perform a normal update. If you depend on irreplaceable local data, make a tested backup first.

Frequently asked questions

Is Docker Desktop 4.94 available for Linux?

Yes. Docker lists Debian, RPM, and Arch downloads for version 4.94. The rollout is gradual, so the in-app update may arrive at different times.

Does the local logging driver change existing containers?

Docker describes the new default for newly created Linux containers. Check an existing container with docker inspect rather than assuming its driver changed.

Will the update fix WSL integration failures?

It fixes a specific automount timeout introduced in Docker Desktop 4.92.0 and improves several WSL startup messages. Other WSL failures can have different causes.

Does Docker Desktop 4.94 include Docker Engine 29.8.2?

Yes. Docker’s release notes list Docker Engine 29.8.2 among the bundled component updates.

Sources

• Docker Desktop 4.94 release notes
• Docker local logging driver documentation
• Docker Engine 29 release notes
• containerd 2.3.6 release