Codex app on Windows: WSL agent mode fails with: Error creating task Invalid request: AbsolutePathBuf deserialized without a base path

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

• #14461

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Windows Codex cannot start when WSL mode is enabled (terminalShell=wsl) #14461 _Powered by Codex Action_

I reviewed #14461 and I do not think this is a duplicate.

#14461 appears to be a startup/init crash when WSL mode and terminalShell=wsl are enabled.

My issue is different:

• the app starts successfully
• the failure occurs when creating a task / submitting a prompt
• the specific error is Invalid request: AbsolutePathBuf deserialized without a base path

They may be related WSL/Windows path-handling bugs, but the failure point and error signature are different.

Also happening with me

Also with me

same problem here

Same here

same for me

Here stuck on login screen, after configure wsl to be environment unable to login, and need to drop .codex folder to go back to windows environment.

Still happening! For me it worked until about a week ago, and after one of the recent updates, Im getting the same exact behavior. Plugins won't load with that same AbsolutePathBuf error, and the same for sending a prompt.
All my work in WSL got cut off completely.

The Codex now has Pets, but the bugs haven't been fixed.

having the same problem, newest updates degraded the windows app

Update

I found a workaround that restored WSL agent mode for me, including project chats being created/saved again and plugins becoming available again.

This may be a related issue rather than the exact same AbsolutePathBuf failure, but it seems tied to the same Windows/WSL boundary.

On my machine, CODEX_CLI_PATH was set to a Windows Codex executable even while the app was configured for WSL agent mode:

[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")

It returned something like:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\<hash>\codex.exe

That appears to be wrong for WSL agent mode. The app was trying to run a Windows codex.exe while configured for WSL, which caused WSL mode to break.

I checked the WSL runtime cache under:

C:\Users\<user>\.codex\bin\wsl\

and found a Linux Codex binary there:

C:\Users\<user>\.codex\bin\wsl\<hash>\codex

I verified it from PowerShell:

wsl -- file /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex
wsl -- /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex --version

Output confirmed it was a Linux ELF binary and printed a valid Codex CLI version, for example:

ELF 64-bit LSB pie executable, x86-64
codex-cli 0.142.0-alpha.6

Then I set CODEX_CLI_PATH to that WSL cached binary:

[Environment]::SetEnvironmentVariable(
  "CODEX_CLI_PATH",
  "C:\Users\<user>\.codex\bin\wsl\<hash>\codex",
  "User"
)

After fully closing/reopening Codex, WSL agent mode started working again.

Important detail: this override is global, not scoped by agent mode. So if I switch back to Windows native mode while CODEX_CLI_PATH points to the Linux ELF binary, Codex fails to start with:

Failed to spawn Codex CLI at C:\Users\<user>\.codex\bin\wsl\<hash>\codex

For Windows native mode, I have to unset it:

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")

So the current workaround is:

WSL agent mode:
CODEX_CLI_PATH = C:\Users\<user>\.codex\bin\wsl\<hash>\codex

Windows native mode:
CODEX_CLI_PATH = unset

This suggests the app/update may be setting or preserving CODEX_CLI_PATH incorrectly across agent modes, or not scoping it per selected agent environment.

I also noticed that projects remain visible across modes, but chats under projects can differ between Windows native and WSL agent mode. WSL-created transcripts appear to be saved under the Windows .codex directory via /mnt/c/Users/<user>/.codex/..., but the UI seems to index/group sessions differently depending on the selected agent environment/path identity.

So there may be at least two separate but related problems here:

1. WSL mode can be pointed at a Windows codex.exe through CODEX_CLI_PATH, breaking startup/runtime behavior.
2. Even when WSL mode starts, project/session/plugin path handling still seems sensitive to Windows vs WSL path identity, which may be related to the AbsolutePathBuf / UNC path translation failures reported in this issue.

Also happens with me.

I can confirm this still reproduces on Codex Desktop Windows 26.623.5175.0.

Setup:

• Repo lives on F:\veildaemon
• WSL sees it as /mnt/f/veildaemon
• Windows Native agent runtime works
• WSL agent runtime immediately fails on new chat/task creation

Error:
Invalid request: AbsolutePathBuf deserialized without a base path

Important detail:
Using Windows Native for the agent while keeping the integrated terminal shell set to WSL works. The failure only appears when Agent Environment is switched to WSL.

I also appear to be hitting the related non-C drive path mapping issue from #28174. Codex has produced/remembered multiple dialects for the same repo:

• F:\veildaemon
• /mnt/f/veildaemon
• C:\mnt\f\veildaemon

A C:\mnt\f junction can help old thread working-directory resolution, but it does not fix new WSL-runtime task creation. New task creation still fails in WSL mode with the AbsolutePathBuf/base path error.

Feedback ID from my report:
no-active-thread-019f0a14-dfd3-7742-8f7a-300942fcb7fb

Related issue I opened:
#30373

I can reproduce the same failure when switching Codex Desktop on Windows to the WSL agent/runtime while the selected workspace path is the Windows UNC form for WSL.

Sanitized setup:

• Host: Windows Codex Desktop
• WSL distro: Debian 12
• Workspace selected in Desktop as a Windows UNC path: \\wsl$\\Debian12\\home\\<user>\\code\\<private-repo>
• Equivalent WSL-native path: /home/<user>/code/<private-repo>

User-visible errors:

Error creating task
Invalid request: AbsolutePathBuf deserialized without a base path

Also seen when starting a conversation:

Invalid request: AbsolutePathBuf deserialized without a base path

What seems important in this repro is the path identity mismatch: Desktop is carrying a \\wsl$\\... Windows UNC path while the agent runtime has been switched to WSL. Using the WSL-native path form (/home/<user>/code/<private-repo>) is the expected representation for the WSL side, while the UNC path appears to be passed into a code path that expects an AbsolutePathBuf with a base path.

Expected behavior:

• Switching the agent/runtime to WSL should either normalize \\wsl$\\<distro>\\... to the corresponding WSL-native path before task creation, or reject that workspace path with a clear actionable message.
• Creating a new task/conversation should not fail with the raw AbsolutePathBuf deserialization error.

I have intentionally redacted the username, machine details, and private repository name from this report.

Additional sanitized worktree-specific repro from Windows Desktop + WSL mode.

Setup:

• Host app: Codex Desktop on Windows
• Agent/runtime: WSL2
• Workspace/repository: stored under the WSL filesystem, e.g. /home/<wsl-user>/projects/<repo>
• Desktop project path: WSL UNC form such as \\wsl$\<distro>\home\<wsl-user>\projects\<repo> / \\wsl.localhost\<distro>\...
• Codex CLI observed inside WSL: codex-cli 0.142.3

User-visible failure:

Error starting chat
Invalid request: AbsolutePathBuf deserialized without a base path

This reproduces when creating a new Codex-managed Worktree thread. Cleaning stale Git worktrees does not resolve it; newly created worktree threads still fail.

Important details from the environment, with private values redacted:

# Inside the WSL agent process
CODEX_HOME=/home/<wsl-user>/.codex
WSLENV=...:CODEX_HOME/p:...

# From the Windows environment visible to the session
CODEX_HOME=\\wsl.localhost\<distro>\home\<wsl-user>\.codex

After a failed/new worktree attempt, Git can contain worktree entries whose paths look like the UNC CODEX_HOME was passed into the Linux/Git side as an ordinary relative path, for example:

/home/<wsl-user>/projects/<repo>/\wsl.localhost\<distro>\home\<wsl-user>\.codex/worktrees/<id>/<repo>

So the failure does not appear to be caused by stale Git metadata alone. The stale worktree entries can be pruned, but the next Worktree thread creation repeats the same path shape.

Expected behavior:

• In WSL runtime mode, Codex-managed worktree roots should be WSL-native absolute paths such as /home/<wsl-user>/.codex/worktrees/....
• If Desktop stores or receives a WSL UNC path, it should normalize it to the corresponding Linux path before constructing any request field backed by AbsolutePathBuf.
• A Windows UNC path should not be forwarded into the WSL app-server/Git path as \wsl.localhost... and then interpreted relative to the repository root.

This looks related to #18506 and #30436, but the extra data point here is specifically that Codex-managed Worktree creation can materialize the bad UNC-derived path inside the repository and continues to reproduce after normal git worktree prune cleanup.

All usernames, machine names, repository names, and full local paths are intentionally redacted.

Another Windows + WSL agent-mode repro, with a fix that differs slightly from the
CODEX_CLI_PATH override reported above — worth noting because the two are opposite.

Environment

• Host: Codex Desktop on Windows, version 26.623.70822 (released 2026-06-29)
• Agent runtime: WSL (Ubuntu)
• runCodexInWindowsSubsystemForLinux = true
• Triggered by accepting the in-app auto-update; new chats/tasks worked before it.

Symptom
Every new session fails at init, before any real work:
Error creating task — Invalid request: AbsolutePathBuf deserialized without a base path
Error starting chat — Invalid request: AbsolutePathBuf deserialized without a base path

Diagnosis notes that may help others

• It's a request deserialization failure, not a config parse error. Editing or even

deleting config.toml changes nothing.

• There are two .codex homes in play. In WSL the core reads ~/.codex (CODEX_HOME is

empty in the WSL shell), i.e. /home/<user>/.codex — NOT the Windows-side
/mnt/c/Users/<user>/.codex. Time spent editing the Windows-side config is wasted.

• On my machine the User-level env var CODEX_CLI_PATH (set via

[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH","User")) was pointing at a
Windows codex.exe while the app was in WSL mode.

What fixed it for me
Clearing the User-level CODEX_CLI_PATH entirely:
[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")
Then fully quit Codex from the tray (not just close the window) and relaunch.
After that, chat/task creation works again in WSL mode.

Caveat / difference from the earlier workaround
Pointing CODEX_CLI_PATH at the cached Linux ELF core
(C:\Users\<user>\.codex\bin\wsl\<hash>\codex) did NOT work on my build — it failed
with "Failed to spawn Codex CLI at ...\codex", because this launch path tries to
spawn the ELF as a native Windows process. So on this build the fix is to unset
the override, not to redirect it. This suggests the correct value (or whether the
override should exist at all) depends on how the app version does the WSL hand-off,
and that the app may be setting/preserving CODEX_CLI_PATH incorrectly across agent modes.

Unaffected fallback
The standalone WSL CLI (codex in a WSL shell) works fine throughout — it reads
/home/<user>/.codex/config.toml and doesn't go through the desktop path translation.

3 months later the bug is still there...

Codex version: 26.623.141536

I was able to restore Codex Desktop + WSL operation, but it required two separate fixes and a manual workspace reassociation after migration.

Original failing setup

• Windows 11
• Codex Desktop on Windows
• WSL 2 / Ubuntu
• Repository:

• Windows: F:\veilforge
• WSL: /mnt/f/veilforge
• Agent Environment: WSL
• Integrated Terminal: WSL

Codex was mixing path formats such as:

F:\veilforge
/mnt/f/veilforge
C:\mnt\f\veilforge

New WSL-backed chats and tasks failed with:

Invalid request: AbsolutePathBuf deserialized without a base path

Step 1: Restore functionality

The first recovery did not require moving the repository.

I:

• confirmed User and Machine CODEX_CLI_PATH were unset
• fully terminated Codex Desktop
• ran wsl --shutdown
• verified WSL tooling
• verified the existing Windows junction:

C:\mnt\f -> F:\

• relaunched Codex Desktop
• set Agent Environment to WSL
• set Integrated Terminal Shell to WSL

This stopped the AbsolutePathBuf failure and restored usable WSL agent sessions.

However, the app still felt noticeably sluggish while the repository remained under /mnt/f.

Step 2: Remove the remaining sluggishness

I then migrated the authoritative working copy into the native WSL filesystem:

/home/nox/projects/veilforge

Windows and Codex Desktop now access the same repository through:

\\wsl.localhost\Ubuntu\home\nox\projects\veilforge

After moving the working tree and dependencies into /home, the remaining UI and tooling stickiness appears to have resolved.

The migrated repository was fully verified:

• branch and HEAD matched
• Git metadata and local files were preserved
• a fresh Linux-native Python environment installed successfully
• all 813 tests passed
• git fsck --full found no corruption
• Windows Explorer accessed the UNC path normally

The original F:\veilforge repository remained untouched as a fallback.

Step 3: Manually reassociate Codex with the migrated repository

Codex Desktop did not automatically follow the repository from:

F:\veilforge

to:

/home/nox/projects/veilforge

After migration, I had to explicitly open the new repository in Codex Desktop using:

\\wsl.localhost\Ubuntu\home\nox\projects\veilforge

and then confirm:

Agent Environment: Windows Subsystem for Linux
Integrated Terminal Shell: WSL

Existing project entries and chats may remain associated with the old Windows or /mnt/f path, so they should not be assumed to automatically transfer to the new WSL-native workspace.

The migrated repository must be opened as the active Codex workspace so new sessions are rooted in:

/home/nox/projects/veilforge

rather than the previous mounted-drive path.

Observed result

Junction + clean WSL/Desktop restart:
Restores functionality and stops the AbsolutePathBuf failure.

Repository under /mnt/f:
Functional, but noticeably sluggish.

Repository under /home:
Functional and responsive.

Opening the new UNC workspace in Codex:
Required to make Codex use the migrated repository.

This suggests at least two separate issues:

1. A Windows/WSL path identity or runtime initialization bug that can prevent task creation entirely.
2. A performance penalty when the WSL agent operates against a repository on a mounted Windows drive.

There is also a workspace-association limitation: Codex does not automatically recognize that a repository migrated from a Windows or /mnt/<drive> path is the same Git repository now located under /home.

The junction is a usable recovery workaround, but moving the active repository into native WSL storage provides the better long-term experience.

Codex Desktop should normalize Windows drive paths, /mnt/<drive> paths, Linux paths, and WSL UNC paths into one stable project identity. Users should not need to restructure their repositories to prevent /mnt/f/project from becoming C:\mnt\f\project, and they should not need to manually rebuild the project association after moving the same repository into WSL-native storage.

Codex on Windows/WSL is still far too unreliable, and the constant breakage is directly impacting productivity.

Path translation, workspace detection, shell, sandboxing, mount issues etc. keep coming back. A fix lands, then another regression breaks something basic. At this point, it feels like one step forward and three steps backward.

The gap with macOS is obvious. Windows/WSL does not seem to be getting the same level of real-world testing or engineering ownership.

This needs more than another temporary patch. OpenAI needs dedicated Windows/WSL ownership, proper end-to-end regression testing, and release blockers for bugs that break core workflows.

Windows users should not be acting as unpaid regression testers for basic platform support, especially when we are paying customers.

I was able to restore Codex Desktop + WSL operation on Windows after reproducing the same error:

Error creating task
Invalid request: AbsolutePathBuf deserialized without a base path

In my case, the root cause was a user-level CODEX_CLI_PATH environment variable pointing to the Windows Codex CLI installed by WinGet, while Codex Desktop was configured to run the agent in WSL.

The value looked like this pattern:

C:\Users\<user>\AppData\Local\Microsoft\WinGet\Packages\OpenAI.Codex_...\codex-x86_64-pc-windows-msvc.exe

That forced Desktop to use the Windows CLI even though the selected agent environment was WSL.

What fixed it:

[Environment]::SetEnvironmentVariable(
  "CODEX_CLI_PATH",
  $null,
  "User"
)

Remove-Item Env:CODEX_CLI_PATH -ErrorAction SilentlyContinue

Then I fully stopped Codex Desktop, shut down WSL, and restarted both:

Get-Process Codex -ErrorAction SilentlyContinue | Stop-Process -Force
wsl.exe --shutdown

After relaunching Codex Desktop, I kept the original configuration:

Agent Environment: Windows Subsystem for Linux
Integrated Terminal Shell: WSL

Result:

• new project chats/tasks work again
• the workspace resolves to the correct Linux path
• plugins load again
• no project or workspace-state cleanup was required

I verified that CODEX_CLI_PATH was empty at Process, User, and Machine scope before reopening Codex.

Environment observed:

Codex Desktop: 26.614.11602
Windows + WSL2

This may not be the only cause of the issue, but checking for a stale or forced CODEX_CLI_PATH appears to be a low-risk first troubleshooting step before deleting Codex state or re-adding projects.