›_ Codex Issues
Codex Issues / #35134

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

Open 💬 1 comment Opened Jul 24, 2026 by goodboy31985

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
``

  1. Confirm a normal interactive Codex chat starts with that Linux cwd and works.
  2. Create a standalone scheduled automation targeting the saved project.
  3. Wait for the schedule to fire.
  4. 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.

View original on GitHub ↗

1 Comment

Hugo-Polloli · 1 day ago

Additional current reproduction: this remains present on Windows Desktop 26.820.9563.0 with bundled codex-cli/app-server 0.150.0-alpha.8.

I also reproduced it repeatedly on the immediately preceding combination:

  • Windows Desktop package: 26.818.8289.0
  • Bundled codex-cli/app-server: 0.149.0-alpha.4.3
  • Windows 11 host, Ubuntu under WSL2
  • Desktop configured to run agents in WSL
  • Standalone recurring automation, local execution

The useful additional evidence is that the malformed cwd is not limited to WSL UNC project paths. I ran paired minimal canaries against both:

  • a Windows-native workspace path, C:\Users\<user>\Documents\<workspace>
  • a WSL project path, \\wsl$\Ubuntu\home\<user>\projects\<project>

On both app versions, every standalone run created an empty rollout whose only record was session_meta. No automation prompt, user turn, model request, tool call, assistant message, or completion was written.

The session cwd was constructed by treating the absolute host path as relative to the installed app resources directory:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.820.9563.0_x64__<package>/app/resources/C:\Users\<user>\Documents\<workspace>

and for the WSL target:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.820.9563.0_x64__<package>/app/resources/\\wsl$\Ubuntu\home\<user>\projects\<project>

Example failing local thread IDs on 26.820:

  • Windows-path canary: 01a0422d-2b7a-7040-8246-7858fa78f5c5
  • WSL-path canary: 01a0422d-2b7a-7040-8246-787187acdae5

Control experiment:

I converted a real automation to an existing-thread heartbeat targeting a clean thread in the same WSL project. On 26.820 / 0.150, that heartbeat started and completed normally in about 83.5 seconds, received the correct Linux cwd:

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

and executed the saved prompt. Normal interactive WSL threads also work.

This isolates the failure fairly tightly to the standalone cron/new-thread launch path and its Windows-to-WSL cwd normalization. It does not look like a model, authentication, general CLI, project, or general WSL execution failure.

The behavior survived an app update from 26.818 / 0.149 to 26.820 / 0.150. I have retained the rollout metadata and desktop logs, but have not attached raw files publicly because they contain local paths and unrelated session state. I can provide a reviewed, sanitized diagnostic subset if maintainers need it.

This appears to be the same root issue as #20415, with the heartbeat success serving as a useful control and the Windows-native target showing that the bad "prefix app/resources to an already absolute path" operation is broader than UNC conversion alone.