[BUG] Windows: Docker Desktop crashes when started by Claude Desktop - agent shell can't open AF_UNIX socket files under AppData (error 1920)

Preflight Checklist

• [x] I have searched existing issues. #73543 and #76383 describe parts of this but were closed as inactive without a fix; this report adds trace evidence connecting the socket failure to MSIX AppData redirection. Related open report #94254 covers AppData redirection; this report focuses on AF_UNIX access failures and Docker crashes.
• [x] This is a single bug report
• [ ] I am using the latest version of Claude Code. The Claude Code bundled with Claude Desktop was 2.1.293 and the latest was 2.1.296 on the day of testing. The bug is in Claude Desktop's MSIX packaging, not in a Claude Code release.

What's Wrong?

On Windows, Claude Desktop (MSIX package Claude_pzs8sxrjxfjjc) runs Claude Code's shell, and every process started from it, under the package's AppData file-system virtualisation. The process chain is explorer.exe → Claude.exe (from C:\Program Files\WindowsApps\Claude_…\app) → claude.exe → shell.

In that context, opening a Unix-domain socket file (reparse tag 0x80000023) under %APPDATA% or %LOCALAPPDATA% fails with ERROR_CANT_ACCESS_FILE (1920, "The file cannot be accessed by the system"):

• rename, delete and fsutil reparsepoint query all fail, even when elevated;
• %LOCALAPPDATA%\Temp, the profile root and C:\ are unaffected;
• the same files open normally from a process outside the package context, for example one launched through explorer.exe or Win32_Process.Create.

Impact: Docker Desktop started by the agent crashes on every start once a previous session's sockets exist. Docker renames them at start-up, and the rename fails. Only the user sees the dialog. The agent just sees docker failing to connect to npipe:////./pipe/dockerDesktopLinuxEngine, so it retries, kills processes and renames folders. Over about seven weeks on one machine, Claude Code and Codex agents together started Docker about 49 times and spent about 4.7 hours waiting on it.

New top-level AppData folders that Docker creates, such as docker-secrets-engine, also land in %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local, where nothing outside the app can see them.

Evidence:

• A Windows Performance Recorder trace (Minifilter and FileIO profiles) shows an open of C:\Users\<user>\AppData\Roaming\sock-test\mine.sock from the agent shell being issued against \Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\sock-test\mine.sock.
• For the same socket file, fsutil reparsepoint query fails with error 1920 from the agent shell, and succeeds from a process started through explorer.exe or WMI.
• The agent shell has no package identity (GetCurrentPackageFullName returns APPMODEL_ERROR_NO_PACKAGE), yet its AppData access is still virtualised.
• The Codex desktop app, also MSIX, shows the same Docker crash on the same machine, which is consistent with a shared package-context problem.

What Should Happen?

Processes started by the agent should see and use the real AppData, the same as a normal terminal. Programs such as Docker Desktop that use Unix-domain sockets under AppData should start normally.

Error Messages/Logs

rename C:/Users/<user>/AppData/Local/Docker/run/sailor-ingest.sock C:/Users/<user>/AppData/Local/Docker/run/sailor-ingest.sock.stale: The file cannot be accessed by the system.

> fsutil reparsepoint query "%APPDATA%\sock-test\mine.sock"
Error 1920: The file cannot be accessed by the system.

Steps to Reproduce

1. In a Claude Code session in Claude Desktop on Windows, run this in PowerShell 7:

``powershell
New-Item -ItemType Directory -Force "$env:APPDATA\sock-test" | Out-Null
$s = [System.Net.Sockets.Socket]::new([System.Net.Sockets.AddressFamily]::Unix, [System.Net.Sockets.SocketType]::Stream, [System.Net.Sockets.ProtocolType]::Unspecified)
$s.Bind([System.Net.Sockets.UnixDomainSocketEndPoint]::new("$env:APPDATA\sock-test\a.sock")); [Environment]::Exit(0)
``

1. From the same session, run fsutil reparsepoint query "$env:APPDATA\sock-test\a.sock". It fails with Error 1920.
2. From a normal terminal, run the same command. It succeeds.
3. To clean up, delete %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\sock-test from a normal terminal. The file really lives there, and it can't be deleted from inside the app.

Suggested fix: start the agent's shell and tool processes outside the app container, for example with PROC_THREAD_ATTRIBUTE_DESKTOP_APP_POLICY and PROCESS_CREATION_DESKTOP_APP_BREAKAWAY_ENABLE_PROCESS_TREE. Alternatively, opt the package out of AppData write virtualisation.

Workaround: start Docker Desktop with explorer.exe "C:\Program Files\Docker\Docker\Docker Desktop.exe".

Claude Model

Not sure / Multiple models. The bug isn't model-related.

Is this a regression?

I don't know. It has been happening since at least August 2026.

Last Working Version

_No response_

Claude Code Version

2.1.293 (bundled with Claude Desktop 2.31226.0.0)

Platform

Anthropic API

Operating System

Windows (Windows 11 Enterprise 10.0.26100)

Terminal/Shell

Other: the Claude Desktop Code tab's agent shell (PowerShell and Git Bash)

Additional Information

Docker Desktop 4.89.0, WSL 2.7.13.0. Related: #73543 and #76383 (earlier socket failures), and #94254 (AppData redirection).