[Regression] Windows Desktop 26.721 scheduled automations create blank threads for WSL projects

Start from the Scheduled view and the standalone automation runtime that converts the saved WSL UNC project path into a thread cwd. Use the failing thread ID 019f9324-6806-75b2-a718-833f43a5c87f and inspect the automation run and thread state around path resolution and prompt dispatch. Done means WSL projects use their Linux cwd, dispatch the saved prompt, and finish or surface an explicit terminal error.

Summary

Standalone scheduled automations still fail for projects stored inside WSL on Codex Desktop for Windows 26.721.3996.0.

The schedule fires and a run/thread record is created, but the automation prompt is never dispatched. The resulting thread has zero turns and no assistant output, while the automation run remains IN_PROGRESS.

Related older report: #20415. This new report documents a current reproduction on a substantially newer Desktop build.

Environment

• Codex Desktop for Windows: 26.721.3996.0
• Windows 11 with WSL2 Ubuntu
• Project stored inside WSL
• Linux project path: /home/<user>/<workspace>/deploy
• Saved project works normally for interactive chats
• Automation kind: standalone recurring automation
• Execution environment: local
• Model: gpt-5.6-sol

Reproduction steps

1. Configure Codex Desktop to use WSL.
2. Open a project located inside the WSL filesystem, for example:

   /home/<user>/<workspace>/deploy
   

3. Confirm a normal interactive Codex chat starts with that Linux cwd and works.
4. Create a standalone scheduled automation targeting the saved project.
5. Wait for the schedule to fire.
6. Open the generated run in Scheduled.

Deleting and recreating the automation against the same saved project does not resolve the problem.

Actual behavior

The Scheduled view shows that the task fired, but there is no Codex response.

The saved automation stores the project cwd as a WSL UNC path:

\\wsl.localhost\Ubuntu\home\<user>\<workspace>\deploy

At runtime, the created thread receives a malformed cwd formed by prefixing the Windows Store app resources directory to that UNC path:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.721.3996.0_x64__<package>/app/resources/\\wsl.localhost\Ubuntu\home\<user>\<workspace>\deploy

Local state after the run:

• automation_runs.status = IN_PROGRESS
• source_cwd is the WSL UNC path
• a real thread ID is created
• thread status becomes idle
• thread contains zero turns
• preview is empty
• automation user prompt is absent
• assistant output is absent
• no explicit error is surfaced in Scheduled

Concrete failing thread ID for backend correlation:

019f9324-6806-75b2-a718-833f43a5c87f

The failure occurs before model execution and before project-specific tools run.

Expected behavior

For a saved WSL project, a standalone scheduled automation should:

1. resolve the project to its Linux cwd inside WSL;
2. create the thread in that Linux environment;
3. dispatch the saved automation prompt;
4. produce a result or surface an explicit terminal error.

It should not leave a blank thread and a permanently IN_PROGRESS automation run.

Impact

All standalone scheduled tasks targeting this WSL project are affected, including read-only reporting tasks. Recreating the tasks does not help, so scheduled local automation is effectively unusable for WSL-hosted projects on this Desktop build.