[Windows][WSL][Remote] Switching agent environment breaks WSL folder browsing and leaves stale Windows setup state

Environment switch regression: WSL remote folder browsing fails, then Windows setup is reported incomplete

Summary

Switching the Codex desktop app's default agent environment from native Windows to WSL and restarting appears to leave the host in an inconsistent state. WSL-backed folders remain accessible from both Windows and Linux, but Codex Remote cannot enumerate them when creating a new remote project. Switching the default back to Windows then reports that Windows setup did not finish even though the native sandbox setup helper subsequently completes successfully.

Environment

• Codex desktop app: 26.814.5517.0
• Codex runtime: 0.148.0-alpha.15
• Windows: Windows 10 Home 22H2, build 19045.7663
• WSL: 2.7.11.0
• WSL kernel: 6.18.33.2-2
• Distribution: Ubuntu 24.04 on WSL2
• Repository location: under /home/<user>
• Remote client: Codex desktop connecting to the Windows Codex Remote host

Reproduction

1. Start with native Windows as the default agent environment.
2. Change the default agent environment to WSL.
3. Restart the Codex desktop app when prompted.
4. From a remote Codex client, create a new remote project on the Windows host.
5. Enter a WSL source folder such as \\wsl.localhost\Ubuntu-24.04\home\<user>.
6. Observe Unable to load this folder.
7. Change the default agent environment back to Windows and restart.
8. Observe the persistent Windows Setup didn't finish error.

Expected result

• Changing the default environment and restarting should atomically switch the host runtime.
• The remote project picker should enumerate WSL paths that Windows itself can enumerate.
• Switching back to Windows should recognize an already provisioned native sandbox, or surface the specific failing setup operation.

Actual result

• The WSL folder is accessible and enumerable from both Windows and WSL, but the Codex Remote project picker cannot load it.
• Existing registered WSL projects had worked earlier with the same UNC path.
• After attempting to switch back, config.toml still contained runCodexInWindowsSubsystemForLinux = true, suggesting that the state transition did not commit or roll back cleanly.
• The UI continued to report incomplete Windows setup despite successful native setup-helper runs.

Diagnostic evidence

The native sandbox marker exists and is version 5. Installed and cached copies of codex.exe and codex-windows-sandbox-setup.exe have matching SHA-256 hashes, making package corruption unlikely.

An early native setup attempt logged a read-ACL failure for C:\Windows\Temp:

read ACL run completed with errors: ["read mask check failed on C:\\Windows\\Temp ...", "grant read ACE failed on C:\\Windows\\Temp ..."]
setup error: read ACL run had errors

Later attempts repeatedly logged successful completion:

read ACL run completed
setup refresh: processed 57 write roots (read roots delegated); errors=[]
setup binary completed

The WSL-side logs immediately after the restart also included:

Failed to create shell snapshot for bash: Failed to execute bash
Caused by: No such file or directory (os error 2)

The WSL Codex runtime initially also lacked the expected adjacent codex-resources/bwrap binary. Installing the matching bwrap artifact for runtime 0.148.0-alpha.15 restored sandboxed WSL command execution, but did not resolve the remote folder picker or stale Windows setup status.

Confirmed workaround

Explicitly setting native Windows mode with the documented fallback sandbox and restarting restored native Windows execution:

[desktop]
runCodexInWindowsSubsystemForLinux = false

[windows]
sandbox = "unelevated"

After restart, the task reports Win32NT, PowerShell commands execute successfully, and the configuration remains set to Windows/unelevated.

Suspected area

This appears to be a desktop/remote-host state synchronization issue during the Windows-to-WSL environment transition, possibly involving cached app-server selection and incomplete rollback after one setup sub-step fails. The remote folder-listing failure and stale Windows-setup banner may be two symptoms of the same non-atomic transition.

Diagnostics available

• Sanitized native sandbox log from CODEX_HOME/.sandbox/
• Screenshots of Unable to load this folder and Windows Setup didn't finish
• Exact timestamps and runtime hashes

No files from CODEX_HOME/.sandbox-secrets/ will be included.

Related issues

These appear adjacent but are not exact duplicates:

• #39169 — same-generation Windows-to-WSL startup and missing-bwrap failure
• #28094 — WSL path/state normalization problems after environment changes
• #35718 — a separate persistent Windows setup-state failure

Start by reproducing the Windows-to-WSL transition and reviewing config.toml alongside the native sandbox logs in CODEX_HOME/.sandbox/. Compare the remote project picker failure with the setup-helper and WSL-side log entries. Done means the environment switch commits or rolls back atomically, WSL paths load remotely, and the Windows setup status reflects the completed helper.