Windows Desktop + WSL app-server reads WSL ~/.codex instead of the Windows Codex home

What version of Codex is running?

• Codex Desktop app package: OpenAI.Codex_26.506.3741.0_x64
• codex-cli 0.130.0-alpha.5

What subscription do you have?

Pro

Which model were you using?

GPT-5.5

What platform is your computer?

Windows 11 Desktop app with WSL2 Ubuntu enabled. The Codex app is the Windows desktop app, but the app-server is launched through WSL.

What issue are you seeing?

In this hybrid Windows Desktop + WSL setup, Codex appears to read different config homes depending on launch context:

• The Windows-side CLI / desktop settings UI use the Windows Codex home.
• The WSL app-server launched by the Windows desktop app reads the WSL user's ~/.codex/config.toml.

That creates split-brain config behavior. A feature flag or setting changed in the Windows config can silently differ from what the running app-server actually uses.

This caused user-visible issues here:

1. Deprecation warnings in the desktop UI were coming from deprecated keys in the WSL config, even though the Windows config no longer had those keys.
2. The shell-runner regression tied to unified_exec reappeared because the WSL config still had unified_exec = true while the Windows config had already been set to false.

Steps to reproduce

1. Use Codex Desktop on Windows in a WSL-backed workflow.
2. Make the Windows config and WSL config intentionally differ:

Windows config:

[features]
unified_exec = false
multi_agent = true
hooks = true

WSL config:

[features]
unified_exec = true
collab = true

1. Launch Codex Desktop and open a WSL-backed workspace.
2. Observe desktop behavior such as:

• config deprecation warnings
• effective shell-runner behavior
• feature state as seen by the WSL app-server

Expected behavior

The Windows desktop app and the app-server it launches should use one coherent config source, or there should be an explicit documented precedence model that is visible to the user.

At minimum, if the app-server is going to use WSL ~/.codex, the desktop app should surface that clearly instead of making the Windows config look authoritative.

Actual behavior

The running WSL app-server used the WSL home config, while the user-facing Windows app configuration lived in the Windows Codex home.

Observed evidence:

• CODEX_HOME=/mnt/c/Users/.../.codex was present in the interactive shell environment.
• The running Windows Codex process launched the WSL app-server with a command line equivalent to:

wsl.exe -d Ubuntu --cd ".../resources" -- /usr/bin/bash -lc "... exec /mnt/c/Users/.../.codex/bin/wsl/codex app-server --analytics-default-enabled"

• That launch path did not visibly pass CODEX_HOME through to the WSL app-server process.
• After inspecting /home/<user>/.codex/config.toml, it contained the deprecated collab = true key that matched the warnings shown in the Windows app.
• Changing /home/<user>/.codex/config.toml immediately changed the effective feature set of the WSL app-server.

Why this is a bug

In a Windows desktop product, users reasonably expect the desktop app's config home to be the config the app actually uses.

Using the WSL user's ~/.codex/config.toml behind the scenes creates:

• confusing deprecation warnings
• feature flag drift
• inconsistent shell-runner behavior
• difficult recovery, because changing the visible Windows config may not fix the live app

Related issue

This seems related to, but distinct from, the shell-runner bug in #22185.

That issue describes the unified_exec failure mode itself. This issue is about the Windows desktop app and its WSL app-server using different config homes, which can unexpectedly reactivate that failure even after the Windows config is fixed.

Suggested fix

One of:

1. Ensure the Windows desktop app passes the intended CODEX_HOME into the WSL app-server process.
2. Standardize on the Windows config home for Windows Desktop sessions, even when the app-server runs inside WSL.
3. If dual-home behavior is intentional, expose the active config path in the UI and logs so users can tell which config file is authoritative.