WSL path resolution broken after 2026-07-22 Store update — task creation fails, sidebar history missing

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

Version 26.715.72359

What subscription do you have?

Pro 100usd/month

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

After the OpenAI.Codex Store package auto-updated on 2026-07-22 (~16:39 local time), the desktop app broke in three related ways. Root cause appears to be a regression in Windows↔WSL path resolution used when runCodexInWindowsSubsystemForLinux = true.

Environment

• Desktop setting (~/.codex/config.toml, [desktop]):

runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

• All trusted project paths in config.toml are stored in WSL-mount form (e.g. /mnt/c/Users/<user>/Dev/<project>)
• Legacy app also installed: "ChatGPT Classic" (package OpenAI.ChatGPT-Desktop, v1.2026.190.0, last built 2026-07-09)

Symptom 1 — "ChatGPT Classic" failed to launch

Error: "ChatGPT failed to start. Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex."
Root cause: OpenAI.ChatGPT-Desktop v1.2026.190.0's app\resources\ contains only app.asar and windowsaddon.node — no bin\ subfolder. The bundled CLI binary is genuinely absent from this build.
winget repair on this exact package completed successfully but did NOT restore the missing bin\ folder — confirms a packaging defect, not local corruption.
Workaround: set CODEX_CLI_PATH env var to an existing codex.exe found in the per-user cache (%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe). This unblocked launch.

Symptom 2 — Non-pinned session/task history missing from sidebar

After the update, every project's task history disappeared from the sidebar except pinned threads.
Underlying data confirmed intact: 154 rollout-*.jsonl session transcripts under ~/.codex/sessions/ and ~/.codex/archived_sessions/, dated 2026-06-11 through 2026-07-21, untouched.
In ~/.codex/.codex-global-state.json, the key sidebar-project-thread-orders (drives the per-project sidebar list) contains only 1 project entry (3 threads) out of 6 known local projects — the rest are empty.
pinned-thread-ids + thread-project-assignments (14 entries) are still populated — this is why pinned threads still render.
A full quit + relaunch did not repopulate sidebar-project-thread-orders, nor touch the legacy session_index.jsonl / codex-history-snapshots-dev.db files — no automatic reindex/migration runs on startup.

Symptom 3 — New task creation fails in every project

Submitting a new task in any project fails immediately with:
"Erreur lors de la création de la tâche — Invalid request: AbsolutePathBuf deserialized without a base path"
Reproduced in both a WSL-associated project and a project never opened via WSL — same error both times, ruling out a per-project path-format mismatch. Points to a shared/global regression in the Windows→WSL path translation that runs before every task execution.

Suspected root cause

Regression in the OpenAI.Codex MSIX build shipped 2026-07-22, in the Windows↔WSL path-resolution/execution-handoff used when runCodexInWindowsSubsystemForLinux is enabled. Likely also affects sidebar project↔thread reconstruction at startup, since project cwd values are stored in the same WSL-mount form.

Impact

Codex desktop app cannot create any new task while WSL execution mode is enabled, on any project.

Workaround

• Symptom 1: CODEX_CLI_PATH env var override (works).
• Symptom 3: not yet tested, but disabling runCodexInWindowsSubsystemForLinux would likely restore task creation at the cost of losing WSL-specific tooling.

What steps can reproduce the bug?

1. Have Codex Desktop configured with runCodexInWindowsSubsystemForLinux = true and integratedTerminalShell = "wsl" in ~/.codex/config.toml.
2. Receive the automatic Microsoft Store update to package OpenAI.Codex (observed: version 26.715.10079.0, applied 2026-07-22 ~16:39 local time).
3. Launch the app and open any existing local project — reproduces on both a WSL-associated project and a project that has never been opened via WSL (pure Windows-native path).
4. Sidebar: only pinned threads appear for that project; all non-pinned task/discussion history is missing, even though the underlying session transcripts still exist on disk under ~/.codex/sessions/ and ~/.codex/archived_sessions/ (154 rollout-*.jsonl files, dated 2026-06-11 through 2026-07-21).
5. In that project, click "New task", type any prompt, and submit.
6. Observe error banner: "Erreur lors de la création de la tâche — Invalid request: AbsolutePathBuf deserialized without a base path"

Note on session id: task creation fails at the request stage, before any session/thread ID is assigned, so there is no new session id to reference for symptom 3. For symptom 2 (missing history), example existing (unaffected/pinned) thread ids from ~/.codex/.codex-global-state.json → pinned-thread-ids: 019f6eb5-b26b-7683-b16b-e0d142e4139b, 019f8036-6def-75e1-8388-2d0f8d49ddb5.

What is the expected behavior?

• Creating a new task should succeed in any project regardless of the runCodexInWindowsSubsystemForLinux setting, with the app correctly translating the project's path to/from its WSL-mount form (/mnt/c/...) without throwing an AbsolutePathBuf/base-path error.
• The sidebar should list the full task/discussion history for every project, not only pinned threads, matching the session transcripts already present on disk.

Additional information

• All raw session data (rollout-*.jsonl transcripts) is confirmed intact on disk — this looks like a pure index/path-resolution regression introduced by the 2026-07-22 update, not data loss.
• A separate, related packaging defect was found on the legacy "ChatGPT Classic" app (OpenAI.ChatGPT-Desktop, v1.2026.190.0): its app\resources\ folder is missing the bin\ subfolder entirely (no bundled Codex CLI binary), causing a startup failure with "Unable to locate the Codex CLI binary". winget repair on this package did not restore the missing folder, confirming it's missing from the shipped build rather than corrupted locally. Worked around via a CODEX_CLI_PATH environment variable pointing to a cached codex.exe. Flagging in case it's related to the same release train.
• Happy to provide further config/log excerpts (with PII redacted) if useful for reproduction.