Codex Desktop automations do not dispatch prompt correctly for WSL workspaces

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

• #19969
• #19011
• #20076

Powered by Codex Action

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.

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.

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.

I can reproduce this on a newer Windows Desktop build, so the issue is still present as of 2026-07-24.

Environment

• Codex Desktop for Windows: 26.721.3996.0
• WSL2 Ubuntu
• Project is stored inside WSL at /home/<user>/<workspace>/deploy
• Automation kind: standalone recurring automation
• execution_environment = "local"
• Model: gpt-5.6-sol

Reproduction

1. Open a WSL-hosted project in Codex Desktop. Interactive chats correctly use a Linux cwd such as:

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

1. Create a standalone scheduled task targeting that saved project.
2. Let the scheduled task fire.
3. The Scheduled UI shows the task input/run, but there is no Codex response.
4. Deleting and recreating the automation against the same saved project does not fix it.

Observed local state

The saved project itself resolves correctly to the Linux path, but the automation stores its cwd as:

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

At the scheduled time, an automation_runs row is created with:

• status: IN_PROGRESS
• source cwd: the WSL UNC path above
• assistant output: empty
• archived reason: empty

A real thread is created, but its cwd is incorrectly composed by prefixing the Windows Store app resources directory to the UNC path:

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

The resulting thread is idle, has zero turns, an empty preview, and no user automation prompt or assistant message. The automation run remains IN_PROGRESS.

Concrete failing thread ID for backend correlation:

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

This appears to fail before model execution or Forge/project tooling begins. Interactive chats in the same WSL project continue to work normally with the correct Linux cwd.

Expected

The standalone automation should translate the saved WSL project to its Linux cwd, dispatch the saved prompt, and either produce a result or surface an explicit failure instead of leaving a blank thread and an IN_PROGRESS run.