Failed to Connect to the Docker API at npipe ////./pipe/dockerdesktoplinuxengine: Check If the Path Is Correct and If the Daemon Is Running (7 Fixes for Windows)

That error means Docker Desktop's Linux engine named pipe isn't accepting connections on your Windows machine — so there's nothing listening at //./pipe/dockerdesktoplinuxengine and Windows returns "The system cannot find the file specified." The pipe only exists while the Docker Desktop Linux VM is actually running, and it disappears if the app is closed, stuck on the start screen, misconfigured to Windows containers, or if your user account can't open the pipe. Fix the daemon first, then the client.

You'll see this in PowerShell, CMD, Git Bash, or inside VS Code when you run something like docker ps, docker compose up, or a devcontainer build that expects a running engine. The message is unambiguous once you read it in two halves: the client can't find the pipe, and the pipe isn't there because the engine isn't up. Below is a working order of fixes, from the fastest check to the deepest repair, plus what to do when Docker Desktop claims to be running but the pipe still won't open.

Check Docker Desktop Is Actually Running, Not Just Launched

The single most common cause is that Docker Desktop is installed and configured but not currently running. The tray whale icon tells you the truth. Open the system tray (the ^ arrow near the clock), find the Docker whale, and click it.

If you right-click the tray icon and the only option is "Switch to Linux containers…", you're in Windows-container mode. That mode does not create the dockerdesktoplinuxengine pipe, so every Linux-engine command fails with exactly this error. Switch modes and give the VM a minute.

The second subtlety: on a cold boot, Windows can report the app as running before the Linux engine finishes initializing. Docker Desktop's own troubleshooting documentation describes this startup sequence and recommends waiting until the tray tooltip reads "Docker Desktop is running." If you script anything (CI runners, task scheduler, login scripts), add a retry loop rather than firing docker the moment the app launches.

Close and reopen the app cleanly if the icon is stuck mid-animation for more than a few minutes. Right-click the tray icon → "Quit Docker Desktop," wait for the whale to disappear entirely, then relaunch. A half-quit process holding the pipe open is rarer than a plain "not running," but it happens and looks identical from the client side.

Confirm the Named Pipe Exists Before Touching Anything Else

Windows exposes named pipes as filesystem-like objects, so you can list them from PowerShell. Run this and look for the Docker entries:

You should see docker_engine and dockerdesktoplinuxengine (and related pipes like dockerdesktopbackendengine on newer builds) in the output. If dockerdesktoplinuxengine is absent but the tray says running, the engine's API listener hasn't come up — restart Docker Desktop and check again. If the pipe is listed and you still get "cannot find the file specified," the problem is almost certainly permissions or a client pointing at the wrong pipe, which the next two sections cover.

Run the same check from an elevated PowerShell window as well. If the pipe is visible to Administrator but not to your normal account, you've isolated a permissions problem rather than an engine problem. That distinction saves you from uninstalling and reinstalling Docker Desktop when the fix is a group membership change.

One caveat about the older docker_engine pipe: some tools and tutorials hard-code \.\pipe\docker_engine, which is the legacy pipe name. Current Docker Desktop builds on Windows publish the Linux engine at dockerdesktoplinuxengine and route docker_engine as an alias for compatibility, but not every third-party client follows the alias. If a specific tool fails while docker ps works, check that tool's documentation for which pipe name it expects on Windows.

Delete the docker context That Points at the Wrong Socket

The Docker CLI resolves where to connect through contexts. A stale or manually-added context can point at a pipe that doesn't exist on your machine, producing this error even when the engine is healthy. List them:

The active context has an asterisk. On a standard Docker Desktop install, the active context should be desktop-linux, whose endpoint is npipe:////./pipe/dockerdesktoplinuxengine. If you see an odd context active — a leftover default pointing at npipe:////./pipe/docker_engine, or a custom context from a tutorial — remove it or switch back:

and, if a broken one keeps coming back:

Here's the failure case most guides skip. The docker context command itself is a client-side operation that doesn't need the engine, so it works even when everything else fails — but only if DOCKER_HOST isn't overriding it. If DOCKER_HOST is set in your environment, it wins over the context. Check with echo $Env:DOCKER_HOST in PowerShell or echo %DOCKER_HOST% in CMD. Delete it in the GUI (System Properties → Environment Variables) or with Remove-Item Env:DOCKER_HOST for the session, then re-run docker ps. Tools like VS Code's Docker extension, devcontainers, and some IDEs also carry their own DOCKER_HOST setting inside their config, so a machine-wide fix won't touch those — check the tool's settings page if only one app misbehaves.

Fix Access Denied: Add Your Account to docker-users

Docker Desktop's named pipe is protected. On Windows, membership in the local docker-users group is what grants non-admin accounts permission to open the pipe, and Docker's Windows install adds your account automatically when you install as the user who will run containers. Problems appear when the account was added by a different admin, when the machine is domain-joined and policy overrides local groups, or when you install for "all users" but only the installing account got the group entry.

Check membership in an elevated PowerShell:

If your username isn't listed, add it:

Then sign out and back in. Group membership is evaluated at logon, so a plain restart of Docker Desktop won't pick it up — this is the step people skip, and they conclude the fix "didn't work" when the group change simply hasn't taken effect.

The classic symptom here is "it works in an Administrator terminal but not in a normal one," or "it works for the admin who installed it but not for the second developer on the machine." Docker's own documentation on installing Docker Desktop for Windows covers this group and the logoff requirement. Rarer causes of Access Denied at the pipe: security software intercepting named-pipe access, and group policy that strips local group memberships on logon in managed environments — in the latter case, your IT admin needs to add the group assignment via policy.

Restart the Engine Properly: Quit, Kill Stale Processes, Reset

When the tray says running, the pipe is listed, permissions are fine, and clients still fail, the engine is wedged. A clean restart sequence is worth more than three random reboots.

1: Right-click the tray whale → Quit Docker Desktop. Wait until the icon is gone from the tray. 2: Open Task Manager, Details tab, and end any surviving com.docker.backend.exe, com.docker.build.exe, dockerd.exe, docker-desktop.exe, or vpnkit.exe processes. A zombie backend holding a half-open pipe is exactly the state that produces this error with the app "running." 3: Relaunch Docker Desktop and wait for "Docker Desktop is running." 4: Run docker version. You want both a Client and a Server block; a Client-only response means the engine still isn't reachable.

If the wedged state recurs after every reboot, the Linux VM disk image is the usual suspect. Docker Desktop's documented "Clean / Purge data" option in the Troubleshoot (bug icon) panel resets the VM — it deletes all local containers and images, so export anything you need first with docker save. The troubleshoot panel also offers "Restart" (gentler, keeps data) and, in recent versions, a "Reset to factory defaults" that wipes settings as well. Try Restart first; purge only when restart doesn't hold.

Before you purge, capture a diagnostics bundle: Troubleshoot panel → "Get support diagnostic." It packages engine and VM logs into a zip you can attach to a Docker support thread. If the failure is WSL-related (next section), those logs will show it, and you'll avoid repeating the diagnosis after a clean reinstall.

If You Use WSL 2, Repair the Backend Before Reinstalling

Docker Desktop on Windows runs its Linux engine in a WSL 2-backed VM. When WSL itself is broken or outdated, Docker Desktop can show "running" while the engine never binds the pipe. Test WSL independently in PowerShell:

You should see a default version of 2 and the docker-desktop distributions listed. If wsl --list fails or hangs, fix WSL first: wsl --update, then wsl --shutdown, then relaunch Docker Desktop. Windows' own WSL documentation is the authority for which Windows build supports which WSL version — Windows 10 builds before the 2004 update can't run WSL 2 at all, and Docker Desktop's current system requirements list Windows 10 64-bit (build 19044 or later) or Windows 11 as the supported floor. On an older build, you'll chase this error forever; the answer is a Windows update.

A known edge case: companies that disable virtualization in BIOS or block the "Virtual Machine Platform" Windows feature. Docker Desktop installs, the tray icon appears, and the engine can never start because the hypervisor isn't available. Check Task Manager → Performance → CPU for a "Virtualization: Enabled" line. If it says Disabled, that's your root cause, and no amount of restarting Docker Desktop will help.

After wsl --shutdown, give the system ten seconds before relaunching Docker Desktop. The shutdown tears down the utility VM, and launching into a half-torn-down VM is a reliable way to reproduce a stuck engine. If the docker-desktop distro is missing entirely from wsl --list, run the Docker Desktop installer again in repair mode — it re-registers the distro without wiping your images.

Reading the Error's Other Variants: Unsupported OS and Client-Only Responses

The same root cause shows up as different messages depending on the client. docker info may report "The system cannot find the file specified" in an Errors: block; the Docker VS Code extension shows "Failed to connect. Is Docker running?"; Testcontainers and .NET tooling surface "Docker is either not running or not configured." All of them reduce to the same check from Section 2: does \.\pipe\dockerdesktoplinuxengine exist, and can your account open it?

Watch for one misleading variant: docker version printing the Client section and then erroring at Server. That's the client succeeding and the pipe failing — which is normal when the engine is genuinely down, and also normal when DOCKER_HOST points somewhere nonexistent. The client binary never needs the daemon; only server-side calls do. If someone tells you "Docker is installed, so the error is a bug," this is the distinction to correct them on.

Version matters here too. Older Docker Desktop releases (pre-4.x era, and Docker Engine 19.x) used \.\pipe\docker_engine for the Linux engine on Windows; the dockerdesktoplinuxengine pipe arrived with context-based routing in the Docker Desktop 4.x line. A tutorial written for 2019-era Docker will tell you to check docker_engine and set DOCKER_HOST=npipe:////./pipe/docker_engine — on a current install, that's how you create this error. Trust docker context ls over any tutorial's hard-coded pipe string.

If you've worked through all of the above and the pipe still never appears, a full uninstall matters: remove Docker Desktop from Apps & Features, reboot, delete %APPDATA%\Docker and %PROGRAMDATA%\Docker, and reinstall from Docker's official download. That clears corrupted config the troubleshoot panel doesn't touch — and it's the last step, because it costs you your local images and settings.

FAQ

Does this error mean Docker isn't installed?

No — it usually means Docker is installed but the Linux engine isn't running or the client is pointed at the wrong pipe. The install check is docker --version, which works without a daemon; the connection check is docker version, which fails at the Server block when the pipe is absent. If docker --version fails too, the CLI isn't on your PATH, a different problem.

Why does it work in an Administrator terminal but not my normal one?

That pattern points to the docker-users local group. Non-admin accounts need membership to open the protected named pipe, and group changes only apply after a sign-out and sign-in. Check with net localgroup docker-users and add your account if it's missing. If policy manages the machine, your admin may need to assign membership centrally.

Can I set DOCKER_HOST to fix the connection manually?

You can, and the correct value on a current Docker Desktop install is npipe:////./pipe/dockerdesktoplinuxengine, but setting it is usually a workaround for a stale environment variable rather than a fix. The cleaner path is to unset any DOCKER_HOST override and let the desktop-linux context resolve the pipe. A hard-coded DOCKER_HOST survives reinstalls and is a recurring source of this exact error.

Is this the same as "Cannot connect to the Docker daemon"?

Effectively yes — same engine, different clients. On Linux the client reports a missing socket at /var/run/docker.sock; on Windows the equivalent is the missing named pipe, and the wording is "The system cannot find the file specified." The diagnostic sequence is identical: confirm the daemon is running, confirm the endpoint exists, confirm permissions.

Will resetting Docker Desktop delete my images and containers?

The "Clean / Purge data" option does; the "Restart" option doesn't. Export anything you need with docker save before purging, and prefer Restart repeatedly before resorting to purge. A factory reset additionally wipes settings and contexts, so you'll reconfigure resource limits and any custom contexts afterward.

Does Windows Home support Docker Desktop's Linux engine?

Yes, via the WSL 2 backend, provided the Windows build is current enough — Docker lists Windows 10 build 19044 or later and Windows 11 as supported. Machines below that build can't run WSL 2 and will never bind the pipe. Virtualization also has to be enabled in BIOS for either edition.

How long should the pipe take to appear after launch?

On a warm start, the engine normally binds within 30–90 seconds; a first launch after install or a Windows update can take several minutes. If the tray has said "running" for five minutes and the pipe still isn't listed, treat it as wedged and run the quit-and-kill sequence. Scripts should poll docker version rather than sleeping a fixed time.