Windows Desktop updates repeatedly reset WSL configuration and reintroduce slow startup state

Compare .codex-global-state.json, shared Codex configuration, and Desktop logs before and after an update, focusing on onboarding flags, WSL path forms, MCP startup, and open-target preferences. Reproduce the update cycle and verify that WSL settings remain stable, remote MCP startup is not reintroduced, paths stay normalized, and startup no longer times out.

What version of the Codex App are you using?

Observed on Windows Desktop package:

OpenAI.Codex_26.730.8199.0_x64__2p2nqsd0c76g0

WSL CLI after manual repair/update:

codex-cli 0.146.0

Platform

Windows x64 with WSL2. The user intentionally runs projects and the Codex agent inside WSL, with repositories under the Linux filesystem, e.g. /home/<linux-user>/<project>.

Issue

After multiple Codex Desktop updates, the same local WSL/Desktop configuration problems keep returning. The practical effect is that new chats can become slow or fail to start, WSL projects drift back into Windows/UNC-style state, and the user has to re-apply local repairs after updates.

This has been recurring across several app updates rather than being a one-time migration problem.

Configuration that should persist

The intended setup is:

sandbox_mode = "danger-full-access"
approval_policy = "never"

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

[desktop.open-in-target-preferences]
global = "wsl"

The Windows app and WSL CLI share one Codex home:

%USERPROFILE%\.codex
/mnt/c/Users/<windows-user>/.codex

A Windows-side CODEX_CLI_PATH points to a small wrapper that sets CODEX_HOME and execs the WSL codex binary.

What keeps coming back after updates

After app updates, the following state/config problems have repeatedly appeared again:

1. Onboarding/runtime flags in .codex-global-state.json return to first-run-like values even though runtime is already installed/ready:

{
  "electron:onboarding-primary-runtime-install-ready": true,
  "electron:onboarding-primary-runtime-install-requested": true,
  "electron:onboarding-welcome-pending": true
}

The expected stable state after setup is that runtimeRequested and welcomePending should not keep returning to true.

2. WSL project roots can drift back into Windows/UNC form, e.g. paths like:

\\wsl$\Ubuntu-22.04\home\<linux-user>\<project>
\\wsl.localhost\Ubuntu-22.04\home\<linux-user>\<project>

instead of staying consistently represented as:

/home/<linux-user>/<project>

3. A remote docs MCP server has repeatedly reappeared in global config and caused large startup delays:

[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

When present, Desktop logs showed slow MCP startup/list operations and chat start timeouts, for example:

method=mcpServerStatus/list durationMs=38078
method=mcpServerStatus/list durationMs=56429
method=mcpServerStatus/list durationMs=93544
mcp_request_timeout method=thread/start timeoutMs=30000
method=thread/start durationMs=40544

Removing that MCP from automatic startup restores much faster codex mcp list behavior.

4. Project open-target preferences can end up with a WSL project mapped to terminal:

[desktop.open-in-target-preferences.perPath]
"/home/<linux-user>/<project>" = "terminal"

On the same installation there is also an integrated-terminal/bottom-panel failure being tracked in #25256, so this setting makes the broken terminal path much easier to hit.

Related log symptoms

The same Desktop logs also repeatedly show Windows-side Git/worktree handling failing for valid WSL paths:

Failed to apply worktree shell environment config cwd=/home/<linux-user>/<project> errorMessage="Git is unavailable"
Failed to determine whether developer instructions should omit git guidance for a non-git workspace errorMessage="Git is unavailable"
worker_rpc_response_error errorMessage="Git is unavailable" method=turn-diff-capture-start workerId=git

But Git works normally inside WSL for the same project:

cd /home/<linux-user>/<project>
git --version
git rev-parse --show-toplevel
git status --short --branch

Expected behavior

• Desktop updates should preserve an already configured WSL agent setup.
• Runtime/onboarding flags should not be reset into a first-run state after every update.
• WSL project roots should be normalized consistently and not oscillate between UNC and Linux path forms.
• Remote MCP servers should not be reintroduced into automatic startup in a way that causes 30s+ startup/list timeouts.
• If a setting is invalid for WSL-backed projects, the UI should show an explicit warning instead of silently causing chat/terminal startup failures.

Workaround currently required

The user currently needs a local repair script after updates that:

• updates @openai/codex inside WSL,
• restores shared CODEX_HOME / CODEX_CLI_PATH,
• removes the slow remote docs MCP from automatic startup,
• resets onboarding/runtime flags,
• normalizes WSL roots,
• restores WSL/full-access Desktop config,
• avoids mapping WSL project paths to the terminal open target.

This workaround is fragile because Codex Desktop can overwrite .codex-global-state.json while the app is running, so the repair only sticks after fully quitting the app.

Related issue

The terminal panel symptom appears related to #25256, but this issue is specifically about the recurring post-update configuration/state regression and slow-startup behavior.