Codex Desktop for Windows starts WSL/Ubuntu even when Windows-native mode is selected

I can reproduce this on a newer Codex Desktop build, and I was able to isolate the command that starts WSL.

Environment

• Codex Desktop: 26.730.8199.0
• App server: 0.147.0-alpha.1.2
• Windows 11 Pro 25H2, build 26200, x64
• Agent environment: Windows native
• WSL: 2.7.11.0
• Default WSL distro: docker-desktop (WSL2)
• Another normal distro is installed but stopped
• Docker Desktop AutoStart: false
• com.docker.service: stopped/manual

Docker-specific manifestation

When docker-desktop is the default WSL distro, launching Codex starts it even though Docker Desktop itself is not launched and no containers are running. Task Manager then shows VmmemWSL.

Hyper-V Compute event logs confirm that the WSL VM is created and Docker's internal VHD is mounted:

<user>\AppData\Local\Docker\wsl\main\ext4.vhdx

Inside docker-desktop, only the WSL init process remains; there is no Docker workload.

Isolated reproduction

Starting from a clean baseline:

wsl --shutdown
wsl --list --verbose

Both distros are stopped and VmmemWSL is absent.

These metadata-only commands do not start WSL:

wsl.exe --status
wsl.exe --list --verbose

The following home-directory probe does start the default distro:

wsl.exe /usr/bin/env bash -lc 'printf %s "${CODEX_HOME:-$HOME/.codex}"'

Observed result with docker-desktop as the default distro:

env: can't execute 'bash': No such file or directory
exit code: 127

Despite the command failing, docker-desktop remains running and VmmemWSL remains resident until wsl --shutdown.

The installed Codex Desktop bundle contains a readCodexHomePathFromWslEnv / resolveCodexHomeFromWsl path that invokes this bare wsl.exe command without -d <distro>. This appears to be the short-lived trigger that is easy to miss in process monitoring.

Repeated timing correlation

Across the last seven days, I found nine Codex-launch / Docker-WSL-start pairs. Docker's WSL VM was created 14.9–56.6 seconds after Codex launched:

Codex start           Docker WSL start      delay
2026-08-06 07:25:11   2026-08-06 07:25:50   39.8s
2026-08-06 07:14:09   2026-08-06 07:14:24   14.9s
2026-08-05 12:00:51   2026-08-05 12:01:12   21.3s
2026-08-04 07:29:09   2026-08-04 07:29:29   19.4s
2026-08-03 21:21:25   2026-08-03 21:21:50   25.2s
2026-08-03 07:45:18   2026-08-03 07:45:36   18.0s
2026-08-01 13:03:36   2026-08-01 13:03:56   20.0s
2026-07-30 22:06:37   2026-07-30 22:07:34   56.6s
2026-07-30 08:46:57   2026-07-30 08:47:20   22.4s

Docker Desktop's own host logs had no corresponding launches during the current incident, which further separates this from Docker autostart.

Expected behavior / suggested direction

In Windows-native mode, Codex should not execute a command inside the default WSL distro merely to resolve WSL-side CODEX_HOME.

If WSL home resolution is required, the implementation should first select an eligible user distro, exclude utility distros such as docker-desktop, and invoke WSL with an explicit -d <distro>. A failed optional probe should not leave an unrelated distro running.

This looks like the same root issue as the Ubuntu report, with docker-desktop exposing an additional failure mode because it is an internal utility distro and does not provide bash.

Additional source evidence (sanitized)

I checked the current public openai/codex repository at commit f141dc77f05b91aa758b3f27178329ced79d87a1.

Public repository boundary

• The repository README identifies this codebase as Codex CLI and links the desktop app as a separate experience: README lines 1–7.
• The public Windows codex app implementation only checks whether the Store package is installed and opens a codex://threads/new?... URL (or the installer): windows.rs lines 10–29 and lines 33–73.
• The JavaScript workspace list contains codex-cli, the responses proxy, and the TypeScript SDK; it does not include the Electron desktop shell: pnpm-workspace.yaml lines 1–4.

A full tracked-file search at that commit found no wsl.exe, readCodexHomePathFromWslEnv, or eligible distro list implementation. Therefore the WSL launcher involved here is not present in the public repository snapshot; the public repo alone cannot show this particular call site.

Direct code evidence from the shipped Windows Desktop build

Codex Desktop 26.730.8199.0 ships the relevant production JavaScript inside resources/app.asar. The archive-relative bundle .vite/build/worker.js contains the following minimal excerpts. Whitespace was added; nonessential options and error handling were elided, while identifiers, argument arrays, and string literals are unchanged:

function jW(e) {
  return NW(
    [`/usr/bin/env`, `bash`, `-lc`,
     'printf %s "${CODEX_HOME:-$HOME/.codex}"'],
    `readCodexHomePathFromWslEnv`,
    e
  )
}

function NW(e, t, n) {
  let r = (0, k.spawnSync)(`wsl.exe`, e, { /* ... */ })
}

function kW(e) {
  return [`-d`, e.distro, `--cd`, e.cwd ?? `.`,
          `--`, CW, `-lc`, e.command]
}

This establishes the parameter bug directly:

1. The Codex-home probe passes a Linux command to wsl.exe without -d <distro>.
2. WSL therefore executes it in the current default distro and starts that distro first.
3. The same bundle already has an explicit selected-distro command builder that includes -d e.distro, but the home probe does not use it.
4. If the default distro is docker-desktop, it is started before the probe fails because that utility distro has no Bash. WSL then remains resident as VmmemWSL.

The issue is therefore in the Windows Desktop shell's WSL-side Codex-home discovery path, not Docker Desktop autostart and not the public Rust app-server.