[Windows] Codex Desktop sandbox blocks Docker Desktop named pipe and WSL access

What version of the Codex App are you using?

26.825.3734.0

What platform is your computer?

Windows 11 Pro, x64. Docker Desktop 4.87.0, Docker Engine 29.7.2.

What issue are you seeing?

Codex Desktop can work inside the local repository, but the Windows sandbox blocks both normal Docker Desktop access and the WSL route used by the project tooling.

The same Docker installation works normally from the signed-in user's Git Bash / PowerShell session.

There appear to be two independent sandbox boundaries:

1. Codex cannot read the normal Docker CLI config under the signed-in user's profile.
2. If that first problem is bypassed with a temporary DOCKER_CONFIG located inside the workspace, the Docker CLI starts but the sandbox is still denied access to Docker Desktop's Windows named pipe.

A separate attempt to use the project's existing WSL2-based wrapper also fails because WSL cannot create the instance from the Codex execution context.

Minimal reproduction

Control test outside Codex Desktop

From the signed-in user's normal Git Bash session:

DOCKER_CONFIG="$(pwd)/.codex-docker-test" docker version

with .codex-docker-test/config.json containing only:

{}

returns both Client and Server successfully:

Client:
 Version: 29.7.2
 Context: default

Server: Docker Desktop 4.87.0
 Engine:
  Version: 29.7.2

Docker Desktop is therefore running and reachable from the normal user session.

Test inside Codex Desktop

The normal Docker config path under %USERPROFILE%\.docker\config.json cannot be opened by Codex and returns Access Denied.

To isolate that from Docker Engine connectivity, a temporary Docker config was created inside the already-readable workspace and Codex was asked to run only:

DOCKER_CONFIG="$(pwd)/.codex-docker-test" docker version

Result:

Client:
 Version: 29.7.2
 API version: 1.55
 OS/Arch: windows/amd64
 Context: default

permission denied while trying to connect to the docker API at npipe:////./pipe/docker_engine

This shows that the alternate DOCKER_CONFIG successfully bypasses the profile-directory read denial, but the sandbox still cannot connect to \\.\pipe\docker_engine.

WSL control path

The project already uses a Git Bash -> wsl.exe -> Ubuntu -> Laravel Sail wrapper, so WSL2 would normally provide a second route to Docker Desktop without using the Windows Docker CLI directly.

From Codex Desktop, attempting the WSL-backed command path fails with:

Access is denied.
Error code: Bash/Service/CreateInstance/E_ACCESSDENIED

Outside Codex, WSL2 and the same project tooling work normally.

Expected behavior

A trusted local development workspace should be able to use Docker Desktop through a supported sandbox permission path, or Codex should provide an explicit way to approve/allow the Docker named pipe for that task.

Likewise, invoking an already-configured WSL2 distribution should not fail solely because the request originates from the Codex Desktop sandbox.

At minimum, diagnostics should distinguish:

• filesystem/profile access denial;
• Windows named-pipe access denial;
• WSL service / instance-creation denial.

Troubleshooting and safety notes

• Docker Desktop itself was not reconfigured.
• No Docker daemon TCP endpoint was enabled.
• No ACLs were changed on %USERPROFILE%, .docker, WindowsApps, docker_engine, or WSL.
• No sandbox users/groups or Windows security policies were modified.
• The temporary Docker config contained only {} and was located inside the workspace solely to isolate the profile-read failure from the named-pipe failure.
• The same Docker and WSL operations work outside Codex Desktop under the normal signed-in user.

Related issues

• #41237 — sandbox can read the workspace but receives EPERM on the signed-in user's profile directory; this also reproduces on 26.825.3734.0.
• #40923 — Windows Codex Desktop session receives EPERM when connecting to another existing native named pipe.
• #25076 — similar Docker socket sandbox discrepancy on macOS; this report is specifically Windows + npipe://./pipe/docker_engine + WSL2.

This report is intentionally separate from #41237 because bypassing the profile/config read failure does not restore Docker connectivity: the Docker named pipe remains independently blocked.

Start by reproducing the two Codex Desktop commands described in the report: DOCKER_CONFIG="$(pwd)/.codex-docker-test" docker version and the existing wsl.exe-backed project command. Compare the failures with the successful Git Bash or PowerShell control path and related issues #41237 and #40923. Done means the supported permission behavior is defined and diagnostics distinguish profile, named-pipe, and WSL access denials.