Codex Desktop WSL: legacy tasks with Windows-form persisted cwd fail process launch

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

26.825.5331.0

What subscription do you have?

ChatGPT Pro 5x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop 26.825.5331.0 appears to have fixed the earlier WSL MCP transport problem, but some existing WSL tasks remain unusable because they contain a legacy Windows-form persisted working directory.

This appears to be a separate downstream legacy-task cwd migration/resume compatibility issue, not a recurrence of the earlier mcp_servers.codex_app transport failure reported in #40881, #40894, and #40829.

Environment:

• Codex Desktop: 26.825.5331.0
• Bundled WSL Codex: codex-cli 0.151.0-alpha.7.1
• WSL distro: Ubuntu 24.04.4 LTS
• WSL: WSL2
• Kernel: 6.18.33.1-microsoft-standard-WSL2

Observed behavior

New WSL-hosted tasks created with a valid cwd work normally:

/home/<user>/projects/<project>

An older task that already stores a valid WSL cwd also resumes and executes commands normally.

However, an existing task whose persisted cwd is Windows-form is reconstructed under the Codex Desktop application resources directory.

Example malformed cwd:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_<version>_x64__<package>/app/resources/c:\home\<user>\projects\<project>

When that task invokes even a basic command such as:

pwd -P

command startup fails before /bin/bash runs:

exec_command failed for /bin/bash -lc 'pwd -P; git rev-parse --show-toplevel': CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

Neither pwd nor Git produces output.

Control cases

PASS — newly created WSL project task:

cwd=/home/<user>/projects/<project>

PASS — existing pre-regression task already storing:

cwd=/home/<user>/projects/<project>

FAIL — existing legacy task storing a Windows-form or malformed cwd.

The failure therefore does not affect every existing task or every new WSL task. It appears specific to legacy tasks whose persisted cwd was corrupted during the earlier regression.

Why this appears distinct from #40881 / #40894 / #40829

The earlier:

invalid transport in mcp_servers.codex_app

failure is no longer reproducible on this build.

mcp_servers.codex_app initializes successfully, and Codex Desktop can:

• enumerate projects;
• enumerate tasks;
• create new WSL tasks;
• send messages to existing tasks;
• create and start turns;
• execute commands in tasks with valid WSL cwd values.

For an affected legacy task, the successful sequence before failure is:

1. Desktop finds and loads the existing task.
2. codex_app accepts the follow-up message.
3. The app-server creates and starts the turn.
4. The malformed persisted cwd reaches turn_context.
5. The model issues exec_command.
6. Unified-process creation fails before /bin/bash starts.

This places the current failure downstream of MCP transport and turn dispatch, specifically at process creation using the malformed persisted cwd.

What steps can reproduce the bug?

1. Launch Codex Desktop 26.825.5331.0 on Windows with WSL2 execution enabled.

2. Open an existing/legacy WSL task whose persisted cwd is Windows-form, for example:

   C:\home\<user>\projects\<project>

3. Resume the task and ask it to execute a trivial shell command such as:

   pwd -P

4. The persisted cwd is reconstructed beneath the Codex Desktop application resources directory, producing a mixed path similar to:

   /mnt/c/Program Files/WindowsApps/OpenAI.Codex_<version>_x64__<package>/app/resources/c:\home\<user>\projects\<project>

5. exec_command fails before /bin/bash starts with:

   Failed to create unified exec process: No such file or directory (os error 2)

Control

Create a new task for the same registered WSL project:

/home/<user>/projects/<project>

Run the same command. It succeeds.

An older task that already persisted the valid /home/... cwd also succeeds.

What is the expected behavior?

When resuming a legacy WSL task, Codex Desktop should normalize or migrate its persisted working directory to the valid registered WSL project path, or otherwise detect and recover from an invalid stored cwd.

A Windows-form cwd should not be resolved relative to the Codex Desktop application resources directory.

Existing tasks should remain executable after an application update when their underlying WSL project still exists and is registered correctly.

Additional information

The running Codex Desktop WSL app-server uses the bundled Codex runtime:

codex-cli 0.151.0-alpha.7.1

The original MCP transport failure is not present in current testing. The internal codex_app transport initializes and handles project/task operations successfully.

The earlier error:

Invalid request: AbsolutePathBuf deserialized without a base path

was also NOT reproduced on build 26.825.5331.0 during this retest.

The current distinctive malformed-path signature is:

app/resources/c:\home

The current failure signature is:

Failed to create unified exec process: No such file or directory (os error 2)

A same-install control test using a newly created WSL task with a valid /home/... cwd succeeds.

This appears to be a legacy task cwd migration/resume compatibility defect rather than a general WSL execution or MCP transport failure.

Start by tracing legacy task resume through persisted cwd handling, turn_context, and exec_command in the bundled Codex runtime. Reproduce with the malformed Windows-form cwd and compare it with a valid /home/... WSL task. Done means an existing legacy task resolves to its registered WSL project path or recovers safely, while the control task continues to execute commands.