WSL mode: runtime installer passes Windows-style path to tar inside WSL (extraction always fails); plugin RPCs all hit 30s timeouts causing "Reconnecting / request timed out"

What version of the Codex App are you using (From “About Codex” dialog)?

26.721.3996.0 (package: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0), bundled WSL engine: codex-cli 0.146.0-alpha.3.1

What subscription do you have?

pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

With Agent environment set to WSL, every new task fails with "Reconnecting /5 — request timed out". The same engine binary works fine when run manually inside WSL, and desktop logs reveal two underlying bugs.

Bug 1 — Path-translation bug (blocking): the primary runtime installer spawns tar inside WSL but passes it a Windows-style path (C:\Users\...), so extraction always fails. The app can therefore never update itself to runtime 26.723 and stays stuck on the broken 26.721 behavior — a self-locking failure loop.

From LocalCache\Local\Codex\Logs\2026\07\24\codex-desktop-*.log:

[spawn-async] Spawning process inside WSL
[primary-runtime-installer] Error installing primary runtime bundleVersion=26.723.12215
errorMessage="Failed to extract primary runtime archive:
tar: C\:\\Users\\echo_\\.cache\\codex-runtimes\\codex-runtime-install-G4RVwp\\payload:
Cannot open: No such file or directory
tar: Error is not recoverable: exiting now"
[install-primary-runtime] primary_runtime_install_failed ... release=latest target=win32-x64
[electron-message-handler] Primary runtime install failed after first turn started

Bug 2 — Plugin RPC timeouts: every plugin/list / plugin/installed request completes in almost exactly 30.3–31.4 s — i.e. they all die at a 30s ceiling, matching the "request timed out" surfaced in the UI:

[AppServerConnection] response_routed method=plugin/list durationMs=30355
[AppServerConnection] response_routed method=plugin/installed durationMs=30575
[AppServerConnection] response_routed method=plugin/list durationMs=30433
[AppServerConnection] response_routed method=plugin/list durationMs=30409
[AppServerConnection] response_routed method=plugin/installed durationMs=31123

Evidence that the environment and engine are healthy:

The app-server spawned by the app (codex -c features.code_mode_host=true app-server --analytics-default-enabled) stays alive with a stable PID while the app shows "Reconnecting" — no crash loop.
Running the same binary manually inside WSL as a TUI (CODEX_HOME=/mnt/c/Users/<user>/.codex .../codex) works: prompts get responses within a few seconds.
Running it manually as app-server (with and without -c features.code_mode_host=true) starts cleanly with no errors.
Network verified from a non-interactive WSL shell (same spawn style the app uses): proxy env vars present, curl https://api.openai.com/v1/models returns HTTP 401 in ~0.7s total (TLS + proxy path healthy). Proxy on 127.0.0.1:7890.
Native (PowerShell) agent mode works normally throughout.

What steps can reproduce the bug?

Windows 11 + WSL2 Ubuntu (mirrored networking), install Codex Desktop from the Microsoft Store.
Settings → Agent environment: WSL (Integrated terminal also set to WSL).
Sign in with a ChatGPT account, create a new task and send any message.
UI shows "Reconnecting /5 — request timed out"; the desktop log shows the tar Windows-path error and the 30s plugin RPC timeouts quoted above.

What is the expected behavior?

Paths handed to processes spawned inside WSL should be translated to /mnt/<drive>/... form (or the archive should be staged on the Linux filesystem before extraction).
Plugin RPCs should not systematically hit the 30s ceiling; if marketplace scanning on /mnt/c (drvfs) is the bottleneck, it should be async/cached rather than blocking task creation.
WSL mode should create tasks and respond, as native mode does.

Additional information

Possibly related history from the same day, same machine:

Earlier, WSL mode failed with deferred dynamic tool must include a namespace: automation_update (#34433). That error disappeared after an app component update.
Also hit migration 1 was previously applied but has been modified on state_5.sqlite / logs_2.sqlite when the WSL alpha engine opened databases initialized by the Windows-native engine (shared CODEX_HOME). Cleared all .sqlite files to recover — mixed-version DB handling under a shared CODEX_HOME may deserve its own issue.
Setting model_catalog_json to a local copy of models_cache.json eliminated a recurring codex_models_manager: failed to refresh available models: timeout waiting for child process to exit error on startup (same symptom family as #30864).

Happy to provide full logs or run further diagnostics.