›_ Codex Issues
Codex Issues / #27567

Codex app: Scheduled automation run fails with `AbsolutePathBuf deserialized without a base path` and remains stuck `IN_PROGRESS`

Open 💬 2 comments Opened Jun 11, 2026 by danpetruk
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

A scheduled Codex Desktop cron automation fails immediately when starting a local WSL workspace run. The run is created, but turn/start fails with:

Invalid request: AbsolutePathBuf deserialized without a base path

The automation run row remains IN_PROGRESS, so the UI shows the run as still running and opening it hangs/loads forever.

Environment

  • Codex Desktop: OpenAI.Codex_26.608.1337.0
  • codex-cli: 0.138.0-alpha.7
  • OS: Windows + WSL
  • Automation kind: cron
  • execution_environment: local
  • cwd: <absolute-wsl-project-path>

Evidence

The same automation/cwd/git state succeeded with codex-cli 0.137.0-alpha.4.
It failed after updating to codex-cli 0.138.0-alpha.7.

Desktop log:
[automations] Scheduled run failed automationId=<automation-id> errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

The session file for the failed run contains only session_meta; there is no user message, no turn/start, no tool call, and no task completion.

Minimal Reproduction

Start app-server and send a turn/start request with a relative path in sandboxPolicy.workspaceWrite.writableRoots.

writableRoots:["relative-dir"] returns:
Invalid request: AbsolutePathBuf deserialized without a base path

writableRoots:["<absolute-path>"] succeeds.

Expected

The scheduled automation should either:

  • normalize relative writable roots against the thread cwd before sending turn/start, or
  • app-server should deserialize these paths with the appropriate base path guard.

If startup fails, the automation run should be marked failed, not left IN_PROGRESS.

Actual

The scheduler creates a run/thread, turn/start fails before execution, and the run remains stuck as IN_PROGRESS in the local automation run state.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26086

Powered by Codex Action

wmatson · 1 month ago

I can reproduce this on a newer Windows desktop/CLI build, specifically with a WSL project selected through the supported project picker flow.

Environment:

  • Codex Desktop client version reported in logs/config: 26.721.41059 (installed package path reports OpenAI.Codex_26.721.4979.0)
  • Bundled WSL CLI: codex-cli 0.146.0-alpha.3.1
  • Windows 11 host, Ubuntu WSL2
  • Desktop agent configured to run in WSL
  • Standalone cron automation, execution_environment = "local"

Reproduction:

  1. Keep the repository under /home/<user>/code/<repo> in Ubuntu WSL.
  2. Add it to Codex Desktop via \\wsl$\Ubuntu\home\<user>\code\<repo>.
  3. Create a standalone scheduled task targeting that project in local mode.
  4. Let the scheduled run start.

The app's project listing normalizes the project to /home/<user>/code/<repo>, but the saved automation cwd and run source_cwd remain \\wsl$\Ubuntu\home\<user>\code\<repo>.

At 2026-07-28T18:02:02.890Z, the desktop log says:

[spawn-async] Spawning process inside WSL

About 100 ms later:

[automations] Scheduled run failed automationId=<redacted> errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

No model turn was created. The automation run row remained IN_PROGRESS, with zero turns/session content, matching the stuck-run behavior reported here.

This appears to be an additional path-normalization case: the scheduler launches the WSL backend but forwards the Windows UNC project path instead of converting it to /home/<user>/code/<repo> before the app-server request. The same repository is a valid Git worktree when accessed directly inside WSL.

Possibly related broader WSL automation report: #20415.