Windows Codex Desktop local background automations cannot see user-scoped WSL distro

[matteo-liguori]

What version of the Codex App are you using (From “About Codex” dialog)?

Codex_26.506.3741.0_x64__2p2nqsd0c76g0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Background Codex automations on Windows cannot access the installed WSL distro, while foreground/manual Codex chat can access it normally.

In foreground/manual chat, Codex runs as:
desktop-0banqcf\mligu

In background automation context, Codex runs as:
desktop-0banqcf\codexsandboxonline

When the automation runs in that background context, it loses visibility of the user-scoped WSL distro registration and behaves as if no distro is installed.

Observed errors in background automation context:

• wsl.exe -l -v reports:
  Windows Subsystem for Linux has no installed distributions.
• wsl.exe -d Ubuntu ... fails with:
  There is no distribution with the supplied name.
Error code: Wsl/Service/WSL_E_DISTRO_NOT_FOUND

At the same time:

• WSLService, vmcompute, and hns are running
• the logged-in user session is still active
• foreground/manual Codex chat can immediately run the same WSL commands successfully

This makes unattended local automations that depend on WSL fail unless the user interacts in chat and execution returns to the normal user context, which defeats the purpose of those automations.

What steps can reproduce the bug?

Environment:

• Codex desktop app package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Codex desktop product version: 26.506.31421
• Codex runner version: 0.130.0-alpha.5
• OS version: Microsoft Windows NT 10.0.26200.0 x64
• WSL distro: Ubuntu on WSL2

Reproduction steps:

1. Ensure a WSL distro is installed for the logged-in Windows user.
2. In a normal foreground/manual Codex chat, run:
   • wsl.exe --status
   • wsl.exe -l -v
   • wsl.exe -d Ubuntu bash -lc "echo PROBE_OK"
3. Observe that all of those succeed.
4. Create and run a local background Codex automation that executes the same checks without user interaction.
5. Observe that the background run executes under a different Windows identity and cannot see the distro.

What we observed in foreground/manual context:

• whoami = desktop-0banqcf\mligu
• HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss is populated
• wsl.exe -l -v lists Ubuntu
• wsl.exe -d Ubuntu ... succeeds

What we observed in background automation context:

• whoami = desktop-0banqcf\codexsandboxonline
• query user still shows the logged-in user session active
• HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss is empty
• probing HKU\<user SID>\Software\Microsoft\Windows\CurrentVersion\Lxss returns Access is denied
• wsl.exe -l -v says no installed distributions
• wsl.exe -d Ubuntu ... fails with Wsl/Service/WSL_E_DISTRO_NOT_FOUND

Additional launch variants tested in background automation context:

• direct wsl.exe -d Ubuntu ...
• cmd.exe /d /c "wsl.exe -d Ubuntu ..."
• child powershell.exe -NoProfile -NonInteractive -Command "wsl.exe -d Ubuntu ..."
• environment override attempt for USERPROFILE, HOMEDRIVE, HOMEPATH, APPDATA, LOCALAPPDATA, and USERNAME

Result:

• all four variants succeeded in foreground/manual context
• all four variants failed in background automation context

Session id / token usage / context window usage:

• not applicable to the observed failure
• this appears to be a local desktop automation execution-context issue rather than a model context-window issue

What is the expected behavior?

Background Codex automations configured to run locally should be able to access the same installed WSL distro that foreground/manual Codex chat can access, without requiring the user to send a message first.

At minimum, local background automations should run in a context that can see the logged-in user's WSL distro registration, at least as an option when creating the automation.

If that is not supported, Codex should fail with a precise diagnostic explaining that the automation worker context cannot access user-scoped WSL distros, rather than reporting that no distro is installed.

Additional information

Why this looks like a Codex desktop automation-context bug rather than a WSL bug:

• WSL itself is healthy in normal foreground/manual use
• the same machine and same installed distro work immediately in foreground/manual Codex chat
• the failure boundary tracks the Windows identity used by Codex:
  • foreground/manual: desktop-0banqcf\mligu
  • background automation: desktop-0banqcf\codexsandboxonline
• the background context appears unable to access the user-scoped WSL registration under HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss

Primary evidence collected locally:

• WSL state snapshot script
• WSL state snapshot log
• WSL launch-option matrix script
• WSL launch-option matrix log

High-signal conclusion:

• this is not fixed by wrapper choice
• this is not fixed by simple environment-variable overrides
• this does not behave like a normal Linux or WSL engine failure
• this looks like a background automation token/profile/HKCU visibility issue in the Codex desktop app

Suggested fix direction:

• run local background automations in the logged-in user context, or
• provide a supported bridge into that context for local tools like WSL, or
• explicitly detect and report that the automation worker cannot access user-scoped WSL distros