Codex Desktop automations do not dispatch prompt correctly for WSL workspaces

[collinstevens]

Summary

Codex Desktop recurring automations fail or stall when configured for a WSL workspace.

The app settings show:

• Agent environment: Windows Subsystem for Linux
• Integrated terminal shell: WSL

Workspace paths, redacted:

• WSL path: /home/<user>/projects/<workspace>
• Windows WSL UNC path: \\wsl$\Ubuntu\home\<user>\projects\<workspace>

Observed behavior

Different automation configurations fail in different ways:

1. execution_environment = "worktree" + Linux cwd

   • Runs launched with Windows cwd / PowerShell, e.g. C:\projects\<workspace>.
   • $env:CODEX_HOME was null.
   • Runs became archived.

2. execution_environment = "worktree" + WSL UNC cwd

   • Run was archived before a real thread was created.
   • DB row had thread_id = pending:....
   • No session JSONL was created.

3. execution_environment = "local" + WSL UNC cwd

   • A thread was created.
   • Chat immediately showed: Current working directory missing / This chat's working directory no longer exists.
   • The UNC path is invalid inside the WSL agent environment.

4. execution_environment = "local" + Linux cwd

   • A valid project chat was created.
   • The automation prompt was never submitted.
   • Session JSONL only had session metadata and thread title update.
   • No user automation prompt, model request, tool call, or assistant message occurred.

Concrete run IDs

Archived before thread creation:

• Run row: pending:45c38c72-3dc1-4912-b654-d011a5b0e93f
• Automation: weekly-engineering-summary
• Source cwd: \\wsl$\Ubuntu\home\<user>\projects\<workspace>

Created thread but did not dispatch prompt:

• Thread: 019dde5f-1b7d-7981-93e4-22f5a26d55f7
• Automation: weekly-engineering-summary
• Source cwd: /home/<user>/projects/<workspace>
• Status stayed IN_PROGRESS
• Session JSONL had only 2 records: session metadata and thread title update

Earlier runs that launched through Windows/PowerShell:

• Thread: 019dde4a-cffb-7432-bb64-54bae4ab0707
• Thread: 019dde4a-cb15-7201-ac38-f9bc9bdc189b

Expected behavior

For WSL agent environment, automation runs should:

• Use the Linux cwd inside WSL.
• Start the session in WSL, not Windows PowerShell.
• Submit the automation prompt after creating the thread.
• Either complete with an inbox item or expose an explicit error.

Actual behavior

The runner either archives before thread creation, opens a thread with an invalid cwd, or creates a valid thread but never dispatches the automation turn.

Environment

• Codex Desktop on Windows with WSL enabled
• Codex CLI/session metadata showed cli_version = 0.126.0-alpha.8
• Model used by the automation: gpt-5.5

Additional notes

I am intentionally redacting local project, organization, and repository names from paths in this report. The concrete thread IDs above should allow correlation with backend/client logs if available.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop scheduled automations create empty sessions with no prompt or task turn #19969
• Windows Codex Desktop creates automation thread but never starts agent turn #19011
• Codex App Automations on Windows ARM64: “Run now” creates empty read-only session and never submits prompt #20076

Powered by Codex Action

[collinstevens]

I also preserved the relevant local Codex Desktop diagnostic files from these runs (automation DB rows, app logs, session JSONL files, and related SQLite databases/WAL files). I am not attaching them publicly because they include local paths and session/app state, but I can provide a private bundle to maintainers if useful.

[m13v]

the failure across all four configs looks like the same root: the thread-creation layer and the prompt-submission layer are resolving cwd against different namespaces. windows host vs WSL guest, UNC vs linux path, none survive a round trip. hit nearly this on a desktop AX harness when the dispatcher ran in a different process namespace than the target. what worked: resolve canonical path once at registration, store both representations, let each layer pick the one matching its context. the worktree mode silently archiving with pending:thread_id smells like the worktree creator can't see the WSL filesystem from the host.

[tompw89]

I can add a closely matching data point from Codex Desktop on Windows with the agent environment set to WSL.

In my case, execution_environment = "local" with a Linux cwd creates the automation thread, but the automation prompt is never submitted. The saved session JSONL contains only startup metadata and the thread title update. There is no user automation prompt, no assistant message, no tool call, and no token/model activity.

The useful extra evidence is that Desktop logs show the failure at the prompt-submission step:

2026-05-02T09:20:02.146Z warning [automations] Scheduled run failed automationId=hello-world errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

For the affected WSL run, app-server logs show:

• thread/start
• shell snapshot
• SetThreadName { name: "Hello world" }
• no UserInputWithTurnContext
• no turn/start success

When opening the stuck thread later, Desktop logged:

maybe_resume_success conversationId=<thread-id> latestTurnId=null latestTurnStatus=null markedStreaming=true turnCount=0

That explains the visible UI symptom: the thread appears to be stuck/streaming, but there is no turn to resume.

I also compared this with a successful Codex Desktop automation from the Windows-native home on the same machine. In the native case, app-server receives UserInputWithTurnContext shortly after SetThreadName; the payload includes the expected automation seed message (Automation: ..., Automation ID: ..., Automation memory: ...) plus a Windows cwd and workspaceWrite writable roots. The native run then proceeds normally.

So this looks less like a model or prompt issue and more like a Desktop-to-WSL path normalisation problem during the automation turn/start request. My best guess is that one of the path-bearing fields, likely sandboxPolicy.workspaceWrite.writableRoots or a related cwd/environment path, is being sent in a form the WSL/Linux app-server rejects as an AbsolutePathBuf before the automation seed turn is created.

This seems to be the same family as the behaviour reported here: thread creation succeeds, but prompt dispatch never happens for the WSL automation.