›_ Codex Issues
Codex Issues / #30288

Windows Desktop WSL mode times out waiting for cold WSL, falls back to Windows app-server, and hides WSL project chats

Open 💬 0 comments Opened Jun 26, 2026 by MisterRound

Summary

Codex Desktop on Windows in WSL mode appears to give up on WSL too quickly during startup. If the configured WSL distro is cold/stopped and wsl.exe takes more than about 3 seconds to answer, Desktop logs an eligible-distro timeout, starts the Windows app-server instead, and then interprets existing Linux thread cwd values with Windows path semantics.

The visible result is severe: WSL projects still appear in the sidebar, but they show No chats even though the thread database and session JSONL files are still present and the app thread API can list the threads.

This looks like another WSL release-gate gap: a stopped/cold WSL distro is a normal Windows+WSL state and should not make Desktop silently fall back into a path personality that breaks existing WSL project/thread associations.

Environment

  • Windows Desktop app: observed after update to OpenAI.Codex_26.623.4041.0_x64
  • WSL distro: Ubuntu, WSL2
  • Desktop setting: run Codex in WSL enabled
  • Integrated terminal shell: WSL
  • Existing saved projects include WSL UNC roots such as:
  • \\wsl$\Ubuntu\home\<user>
  • \\wsl$\Ubuntu\home\<user>\<project>
  • \\wsl.localhost\Ubuntu\home\<user>\<project>
  • Existing thread rows contain Linux cwd values such as:
  • /home/<user>
  • /home/<user>/<project>
  • /mnt/c/Users/<user>

What Happened

After updating/reopening Codex Desktop:

  1. WSL projects still appeared in the sidebar.
  2. Each WSL project showed No chats.
  3. The current app thread list API could still find the missing WSL threads.
  4. The local thread DB and session files were still present.
  5. The thread API showed existing Linux cwd values being rendered as malformed Windows paths:
  • /home/<user> became C:\home\<user>
  • /home/<user>/<project> became C:\home\<user>\<project>
  • /mnt/c/Users/<user> became C:\mnt\c\Users\<user>

That breaks matching against saved project roots like \\wsl$\Ubuntu\home\<user>, so the sidebar projects exist but have no associated chats.

Evidence

Startup log from Desktop:

[wsl] error retrieving eligible distro error="Error: spawnSync wsl.exe ETIMEDOUT"

Same startup then initialized a Windows app-server:

codex.exe app-server --analytics-default-enabled

Local state was not deleted:

state_5.sqlite still contained thousands of thread rows
sessions/**/rollout-*.jsonl still contained thousands of session files
thread/list via the app API still returned the missing WSL threads

The packaged Desktop app appears to perform the WSL eligible-distro probe with a hardcoded 3 second timeout:

execFileSync("wsl.exe", ..., { timeout: 3e3, ... })

The probe wraps WSL commands such as:

wsl.exe --status
wsl.exe --list --verbose
wsl.exe --list --quiet

A stopped/cold WSL distro can take longer than 3 seconds to respond. Treating that as "no eligible WSL distro" causes the app to choose the wrong runtime/path semantics.

Expected Behavior

If WSL mode is enabled and WSL startup is slow/cold:

  • Desktop should not permanently route the session through Windows path semantics after a single short timeout.
  • It should either wait longer, retry, start WSL explicitly, or keep the UI in a pending WSL state.
  • Existing Linux cwd values should continue to match saved WSL project roots.
  • Existing WSL chat history should remain visible in project grouping.

Actual Behavior

  • The WSL eligibility probe times out.
  • Desktop starts the Windows app-server.
  • Existing Linux paths are rendered as Windows paths like C:\home\<user>.
  • Saved WSL project roots remain UNC paths.
  • Sidebar grouping fails and WSL projects show No chats.

Why This Needs a Separate Fix

There are several related path-rendering and WSL issues, but this repro adds a sharper startup failure mode:

  • The trigger is a cold/stopped WSL distro exceeding a short WSL probe timeout.
  • The failure changes runtime/path personality before thread listing and project grouping.
  • The user's data is still present, so this is not data loss; it is a runtime selection/path-normalization failure.

Related issues and PR areas that look adjacent:

  • #28094: WSL project paths rewritten as C:\home, losing chat associations.
  • #28172: WSL project maps to invalid C:\home path.
  • #24364 / #22796 / #20741: Desktop project history/sidebar shows missing chats while local data exists.
  • #28146 / #28152 / #28122: target-native environment cwd/path rendering work.

Suggested Fix

  • Do not use a hard 3 second WSL eligibility timeout as a decisive fallback to Windows app-server behavior.
  • If WSL mode is enabled, prefer a longer timeout and/or retry with explicit cold-start handling.
  • Preserve the configured WSL runtime/path personality while WSL readiness is pending.
  • Add a release-gate test for Windows Desktop with WSL mode enabled where the distro starts from Stopped.
  • Assert that pre-existing thread cwd values like /home/<user>/<project> still group under saved WSL project roots such as \\wsl$\Ubuntu\home\<user>\<project> after restart/update.

View original on GitHub ↗