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

[StreamVi]

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.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Windows Desktop Full Access tasks intermittently request approvals, especially queued/background tasks #36530

Powered by Codex Action