[Windows][WSL] Codex Desktop rewrites /home project paths as C:\home, loses project chat associations, and reports valid working directories as missing

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.609.41114 • Released Jun 12, 2026

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 with WSL installed

What issue are you seeing?

Summary

After updating the Codex Windows desktop app on June 13, 2026, Codex Desktop stopped handling WSL project paths correctly on one Windows machine.

A project located at:

/home/brett/projects/ssus828

is being stored or interpreted by parts of the desktop app as:

C:\home\brett\projects\ssus828

This invalid path causes all of the following:

Existing project conversations no longer appear beneath their projects.
Projects display “No chats” despite the session transcript files still existing locally.
Threads display: “Current working directory missing — This chat’s working directory no longer exists.”
New desktop conversations inherit the same invalid working-directory state.
The integrated WSL terminal initially attempts:
cd 'C:\home\brett\projects\ssus828'
and fails with “No such file or directory.”
Manually running:
cd /home/brett/projects/ssus828
in that same terminal succeeds.
Native Codex CLI running directly inside WSL works correctly in the same repository.

I updated Codex on two other Windows machines on the same day without this problem, so this may involve a machine-specific state migration or Windows/WSL path normalization failure.

Environment
Windows 11
WSL 2
Ubuntu 24.04
Codex Windows app package observed in:
OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
Codex CLI: 0.139.0
Desktop setting:
Agent environment: Windows Subsystem for Linux
Integrated terminal shell: WSL
Example repository:
/home/brett/projects/ssus828
Repository added through:
\wsl$\Ubuntu\home\brett\projects\ssus828

What steps can reproduce the bug?

Install or update the Codex Windows desktop app.
Set Agent environment to Windows Subsystem for Linux.
Set Integrated terminal shell to WSL.
Restart the app.
Add an existing WSL project through:
\wsl$\Ubuntu\home\brett\projects\ssus828
Start a new conversation in that project.
Ask Codex to run pwd and git status.
Open the integrated terminal.
Actual behavior

The desktop conversation may execute commands in the correct WSL repository, but the app’s thread metadata and terminal initialization use:

C:\home\brett\projects\ssus828

The interface continues to show:

“Current working directory missing — This chat’s working directory no longer exists.”

The project sidebar continues to show “No chats.”

The integrated terminal records:

cd 'C:\home\brett\projects\ssus828'

followed by:

-bash: cd: C:\home\brett\projects\ssus828: No such file or directory

Manually entering:

cd /home/brett/projects/ssus828

works immediately.

What is the expected behavior?

Codex Desktop should preserve the WSL path:

/home/brett/projects/ssus828

The project should:

Open in the actual WSL directory.
Initialize its terminal in that directory.
Associate new and existing threads with that project.
Display existing project conversations.
Not report an existing WSL directory as missing.
History and session impact

Before the update, several active projects had ongoing desktop conversations.

The local Codex state contained:

43 active session transcript files
4 archived session transcript files

Those transcript files were preserved and backed up. They do not appear deleted, but the desktop app no longer displays or associates them correctly with their projects.

Troubleshooting already completed

The following did not resolve the desktop path problem:

Fully restarted Windows.
Removed and re-added the WSL project.
Uninstalled the Microsoft Store Codex app.
Quarantined the entire %USERPROFILE%.codex directory.
Reinstalled Codex from the Microsoft Store with completely clean state.
Installed the standalone Windows Codex CLI.
Set CODEX_CLI_PATH to:
C:\Users\brett\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
Restarted Windows again.
Reconfigured the clean app for WSL.
Created a completely new desktop conversation.
Installed Codex CLI 0.139.0 natively inside Ubuntu WSL.
Installed bubblewrap.

The native Linux CLI works correctly:

pwd returns /home/brett/projects/ssus828
git status works
The correct repository files are visible
No Windows path translation occurs

The issue appears isolated to the Windows desktop app’s WSL project/thread path handling.

Additional information

Additional startup symptom

Immediately after the desktop update, the app also failed to start with:

“Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.”

Installing the standalone Windows CLI and setting CODEX_CLI_PATH allowed the desktop app to launch again, but did not resolve the invalid C:\home... project path.

Severity

Blocking.

I was midstream in several active projects. The repositories and transcript files remain available, but the desktop application can no longer reliably reopen the conversations, associate them with their projects, or maintain a valid WSL working directory.

Regression information

The same Codex update was installed successfully on two other machines on June 13, 2026. Only this machine reproduces the failure.

Attachments

I can provide:

Screenshot of the initial missing CLI binary error.
Screenshot showing “Current working directory missing.”
Screenshot showing the invalid C:\home\brett\projects\ssus828 terminal command.
Screenshot showing the same project working correctly through the native WSL CLI.
A Codex feedback session ID.
Sanitized session metadata or logs if requested.

Feedback session ID
019ec1f5-6fba-7620-8e89-0abf8ebaa3b4

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

Windows app WSL agent mode fails to find bundled CLI and may launch Windows codex.exe via CODEX_CLI_PATH #28086
Codex Desktop fails to run any command in WSL workspace despite Agent Environment set to WSL #27553
# Bug Report: Windows Codex Desktop Shows Empty Project Chats While Mobile Shows History #26624

Powered by Codex Action

Update: reproduced on a second machine

This issue is now reproducible on a second Windows workstation after installing the same Codex update.

The second machine previously had a working Codex Desktop + WSL workflow and active project conversations. After the update, it now shows the same behavior:

WSL projects located under /home/<user>/... are interpreted as invalid paths such as C:\home\<user>\....
New conversations report “Current working directory missing.”
Project conversations do not appear correctly beneath their projects.
The integrated terminal attempts to start from the malformed Windows path.
Manually changing the terminal directory to the correct /home/... path works.
Native Codex CLI installed directly inside WSL works normally in the same repository.

This makes the issue unlikely to be isolated corruption on one computer. It appears to be a repeatable regression introduced by the current Windows Codex Desktop update for WSL-backed projects.

Related existing reports:

Codex Desktop WSL mode starts Windows app-server and leaves thread in PowerShell #21147 — fresh WSL threads start with PowerShell and C:\home\...
Windows Codex + WSL project: older threads lose cwd and terminal tries to cd into malformed WindowsApps/app/resources/\\wsl$ path #23189 — existing WSL threads lose their working directory and project association after an update

Severity remains blocking because multiple active development machines and midstream project conversations are affected.

Same issue, issue started today

same issue there last 18 hrs

I filed a related issue with additional crash/context details and in-app diagnostics: #28172.

My case appears to match this issue:

WSL project root: /home/rgkoppen/codex-work/central-station-audit
Codex Desktop maps it to invalid: C:\home\rgkoppen\codex-work\central-station-audit
Desktop reports current workdir missing / invalid directory
Codex CLI in WSL still works normally

Additional trigger in my case:

Windows PC crashed while Codex Desktop was actively running a task.
After reboot, my desktop chats disappeared, while they were still visible in the mobile app.

In-app feedback ID:

no-active-thread-019ec53c-217c-7c13-99c0-665ce74256ab

This may help correlate logs/diagnostics with the WSL path/worktree/session metadata issue described here.

Comment for openai/codex issue #28094

I am seeing what appears to be the same regression on another Windows + WSL setup.

Related issue:

#28094

Environment

Windows app package: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
Codex app version: 26.609.4994.0
WSL: Ubuntu 24.04
Codex CLI observed in session metadata: 0.139.0
Desktop settings:
- Agent environment: Windows Subsystem for Linux
- Integrated terminal shell: WSL
Project path in WSL: /home/<user>/<project>
Project opened through Windows UNC path:
- \\wsl.localhost\Ubuntu-24.04\home\<user>\<project>
- also tested around \\wsl$\Ubuntu-24.04\home\<user>\<project>

What happens

After the Codex Windows Desktop update on 2026-06-14, new local Desktop chats for this WSL project are stored with Windows-style metadata:

cwd = C:\home\<user>\<project>
source = vscode

The actual project exists and works correctly in WSL:

/home/<user>/<project>

From WSL:

pwd -> /home/<user>/<project>
whoami -> <user>
node -> v24.15.0
npm -> 11.12.1
git root -> /home/<user>/<project>

However, the Desktop thread/session metadata and project association still use:

C:\home\<user>\<project>

User-visible impact

The saved project appears in the sidebar.
The project page shows no visible project chats.
The chats are still present on disk under %USERPROFILE%\.codex\sessions.
session_index.jsonl contains the chat ids, so the chats can appear in search.
The project-scoped chat list does not show them under the project.
Previously, the app also showed "Current working directory missing - This chat's working directory no longer exists" until a Windows junction workaround was added.

Local state evidence

The global Desktop state contains the correct WSL UNC project root:

"electron-saved-workspace-roots": [
  "\\\\wsl.localhost\\Ubuntu-24.04\\home\\<user>\\<project>"
],
"active-workspace-roots": [
  "\\\\wsl.localhost\\Ubuntu-24.04\\home\\<user>\\<project>"
],
"project-order": [
  "\\\\wsl.localhost\\Ubuntu-24.04\\home\\<user>\\<project>"
]

But config.toml gets regenerated with:

[projects.'c:\home\<user>\<project>']

And state_5.sqlite / rollout session_meta contain:

id = <redacted-thread-id>
source = vscode
cwd = C:\home\<user>\<project>
title = <redacted-title>

The rollout file also starts with:

{
  "type": "session_meta",
  "payload": {
    "cwd": "C:\\home\\<user>\\<project>",
    "originator": "Codex Desktop",
    "cli_version": "0.139.0",
    "source": "vscode"
  }
}

Cleanup attempts already tried

Fully restarted Codex Desktop.
Removed stale project/thread state.
Cleared session_index.jsonl.
Removed old session transcript folders.
Removed project trust blocks from both Windows and WSL Codex config.
Cleared local thread rows from state_5.sqlite.
Moved old backups out of active .codex folders.
Reinstalled Codex Desktop.
Re-added the WSL project.

After cleanup/reinstall, new chats still reproduced the same metadata pattern:

source = vscode
cwd = C:\home\<user>\<project>

Workaround

A Windows junction was created so the invalid Windows path resolves:

C:\home\<user>\<project> -> C:\dev2\<project>

where C:\dev2 itself points to the WSL home directory through \\wsl.localhost\Ubuntu-24.04\home\<user>.

This reduces the "working directory missing" symptom, but it does not fix the underlying issue: Desktop still stores and associates the thread using C:\home\<user>\<project> instead of the WSL project path, and the project page still does not show the chats.

Expected behavior

For a WSL project opened from:

\\wsl.localhost\Ubuntu-24.04\home\<user>\<project>

with Agent environment set to WSL, Desktop should preserve or canonicalize the project/thread cwd as:

/home/<user>/<project>

or otherwise consistently associate the thread with the saved WSL project root.

It should not convert /home/<user>/<project> to:

C:\home\<user>\<project>

and project chats should remain visible under the project.

Same issues！Can not believe how many bugs after updating.

A temporary workaround that helped on my Windows + WSL setup:

Fully quit Codex first, otherwise the running process may rewrite stale state back to disk.
Back up %USERPROFILE%\.codex.
Do not restore the whole old .codex folder. In particular, avoid restoring old state_5.sqlite*, .codex-global-state.json, config.toml, plugin cache, and runtime/temp folders.
Reinstall Codex cleanly. If the bundled app\resources\codex.exe exists but fails with Access is denied, copy it to a user-writable path such as %LOCALAPPDATA%\OpenAI\Codex\cli-<version>\codex.exe, then set CODEX_CLI_PATH to that copied executable.
For WSL projects, use one canonical project root only, preferably:
\\wsl.localhost\<Distro>\home\<user>\<project>
Avoid mixing \\wsl$, /home/..., C:\home\..., and \\?\UNC\... in the Desktop project state.
After launch, verify the session is really running inside WSL with:
pwd, uname -a, and a project-file check.
Do not trust the UI setting alone, because the app may still start a hybrid Windows/WSL session.
Restore only the safe history files/folders, such as sessions, archived_sessions, attachments, and session_index.jsonl.
If plugin/list or skills/list remains extremely slow in WSL mode, try disabling plugins temporarily or renaming/clearing .codex\.tmp\plugins after closing Codex.

This is not a real fix, just a recovery strategy to avoid re-importing corrupted path/session metadata. The underlying issue still seems to be a combination of WindowsApps CLI execution, WSL binary resolution, path canonicalization, and plugin cache scanning through /mnt/c.

+1 Here. Genuinely shocking that something like this has come in after an update. The WSL integration is bad enough as it is.

I'm having the same problem as of June 13,2026. I am unable to use Codex Desktop as a result. I have tried all of the recommended solutions here to no avail.

Having the same issue here. Codex works fine within WSL via CLI and inside VS Code; broken within the Windows app.

Same problem. Embarrassing that this was both introduced after an update and wasn't immediately resolved.

Same problem. Hope they resolve this asap

+1 Here. Genuinely shocking that something like this has come in after an update. The WSL integration is bad enough as it is.

Temporary fix.

Go to Microsoft Store -> Profile -> Apps -> turn off auto update

Then go to

https://codex-190977.en.uptodown.com/windows/versions

Download 26.601.2237.0 (3rd June)

Open the file and click reinstall

Now open codex you should see all chat history again.

I have switched to Claude Code because of this. Just sayin'. The WSL integration was already extremely shaky, with the agent losing access to the patch tool and various other things multiple times per day, requiring a full restart of Codex. This bug now just makes the whole situation untenable. Sorry, hope you can win me back one day.

I can confirm that this is a real issue on Windows 11 with WSL integration.

For me, the Windows Codex app has been effectively unusable with WSL for a while. When the agent is running in a WSL/bash environment, it appears to mix Windows and Linux path handling. For example, Codex may try to use Windows-style paths or Windows-side assumptions inside the WSL terminal, which breaks normal WSL workflows.

Interestingly, even the Windows Codex app itself recognized the problem when I gave it a screenshot of a bash terminal window showing the issue. It identified that Codex was trying to use the Windows directory structure in a WSL environment.

This is the first time I have had major problems with WSL integration in Codex. My current workaround is to run Codex directly inside WSL instead of relying on the Windows desktop app’s WSL integration.

In my opinion, this should be treated as a high-priority bug, because many Windows developers use WSL as their main development environment. If the Windows app cannot reliably separate Windows paths/configuration from the WSL runtime, the WSL integration becomes very difficult to use in real projects.

I’m seeing what looks like the same class of bug on Windows Codex Desktop with WSL-backed projects.

Environment:

Codex Desktop: 26.611.8273.0
Windows Desktop app
Projects are under WSL/Ubuntu paths such as \\wsl$\Ubuntu\home\<user>\dev\<repo> / \\wsl.localhost\Ubuntu\home\<user>\dev\<repo>

Additional symptom that may help narrow it down:

If I organize the sidebar by Chronological list, the recent chats are visible.
If I organize the sidebar by Project, those same recent chats disappear.
On cold load, the project chats can briefly show up; after switching focus away from Codex Desktop and back, the project view refreshes and they disappear again.

This does not appear to be data loss. The local session files and thread rows are still present, and the chronological view can still surface the chats. The failure seems specific to project grouping / workspace association for WSL-backed projects.

Relevant log signatures from the Desktop app around the focus/project refresh:

warning [git-repo-watcher] Failed to watch git path
errorCode=EISDIR
errorMessage="EISDIR: illegal operation on a directory, watch '\\\\wsl$\\Ubuntu\\home\\<user>\\dev\\<repo>\\.git'"
path=/home/<user>/dev/<repo>/.git/HEAD

I also saw repeated git-init-watcher failures against a rewritten Windows-looking path, e.g.:

cwd=C:\home\<user>\dev\<repo>
errorCode=EISDIR
errorMessage="EISDIR: illegal operation on a directory, watch 'C:\\home\\<user>\\dev\\<repo>'"

Things that did not resolve it:

Resetting the packaged app WebView/profile cache under AppData\Local\Packages\OpenAI.Codex_...\LocalCache\Roaming\Codex
Rebuilding/repairing local Codex state/session indexes
Aligning stored workspace roots between \\wsl$ and \\wsl.localhost
Verifying the session data still exists locally

Current workaround is to use the Chronological list instead of Project grouping, or avoid WSL-backed projects in Codex Desktop. This looks like project-sidebar grouping depends on a Git/workspace watcher path that fails for WSL/UNC paths, then drops the affected thread associations during refresh.

Another way to work around this is by treating WSL as an another SSH connection for Codex Desktop and adding remote projects instead, skipping all the WSL bs.

Upside is I can get to use computer / browser use now since the WSL backend didn't support it before, and I can easily swap to a windows project now.

Downside is that Codex mobile ~~doesn't let you control remote projects currently~~ (nvm u can), and I had to have Codex brute force fix whatever mess was left behind by the update / me trying to recover it.

Adding another Windows + WSL datapoint that seems related, but with one extra signal around Desktop workspace/remote state.

Environment:

Windows + WSL2
WSL distro: Ubuntu 22.04
Codex CLI in WSL: 0.141.0
Project is a WSL workspace under /home/<user>/<workspace>
Codex Desktop was recently updated before the issue appeared

Observed behavior:

Existing project chats disappeared from the Codex Desktop sidebar/project view after the update.
The chats were not deleted.
The WSL-side Codex SQLite state database (state_5.sqlite on my install) still contained the relevant active thread rows with cwd under /home/<user>/<workspace>.
The Windows-side Codex SQLite state database (state_5.sqlite on my install) did not appear to contain the relevant WSL workspace history.
The same workspace had previously been represented through multiple path/host forms, including POSIX /home/..., WSL UNC roots such as \\wsl$... / \\wsl.localhost..., and a Desktop remote host identity shaped like remote-ssh-discovered:<host>.

Recovery sequence that worked on my install:

I did not modify SQLite.
I backed up the Desktop global state file first.
I normalized the Desktop workspace roots and removed the remote auto-connect entry for the discovered WSL/remote host, while preserving the managed remote connection itself.
After fully exiting and restarting Codex Desktop, the existing chats became visible again in the sidebar/project view.
After restart, selected-remote-host-id was recreated by the app, but the remote auto-connect entry stayed removed and the sidebar remained fixed.

I have not isolated which individual state key was causal, since the recovery involved multiple state changes plus a full Desktop restart.

Interpretation:

This looks related to the same WSL project/thread association class of bug, but in my case the important recovery signal was not a threads.cwd SQLite rewrite. The thread rows already existed under the WSL POSIX cwd. The sidebar seemed to be resolving the project against a different workspace/remote bucket than the one containing the existing threads.

So the affected matching path may involve multiple pieces of state:

WSL path normalization between /home/..., \\wsl$..., and \\wsl.localhost...
Desktop persisted remote state such as selected-remote-host-id / remote auto-connect
Project/sidebar grouping logic that decides which threads belong to the active workspace

User-visible impact is the same: it looks like project chat history was lost, while the underlying local thread data is still present.

I am not attaching full session logs, SQLite databases, or full global state files because they may contain private prompts, local paths, hostnames, and workspace-specific data. I can provide sanitized state-key summaries or redacted before/after observations if useful.

Cross-linking another data point from #29130.

I hit a similar Windows/WSL path-normalization failure after updating Codex CLI from roughly 0.138.0 to 0.142.2. I have WSL installed, but I did not intentionally configure Codex into a split WSL/native state.

In my case the broken state included active metadata split across:

/mnt/c/Users/...
C:\Users\...
\\?\C:\Users\...
C:\mnt\c\Users\...

The invalid C:\mnt\c\Users\... form was especially important: project panes were empty or briefly populated then collapsed. Existing chats were not deleted; project grouping was broken.

The stable repair required migrating all active path surfaces atomically, not only threads.cwd: state DB cwd, local thread catalog cwd, global saved roots/project order/thread hints, session cwd metadata, and config.toml runtime mode. After those were consistently native Windows, project panes worked again.

This seems like the same broader bug family: Codex Desktop/CLI on Windows can create or preserve mixed WSL/native path dialects and then lose project-thread associations.

I can reproduce this on the Windows Codex/ChatGPT desktop app when switching the agent environment between Windows native and WSL.

Observed behavior:

Existing projects remain listed.
Their threads disappear from the sidebar and the projects show “No chats”.
The local transcript files are still present under %USERPROFILE%\.codex\sessions and %USERPROFILE%\.codex\archived_sessions (46 normal sessions and 5 archived sessions in this case).
Fully quitting and reopening the app restores the chats.
Switching the environment again reproduces the problem.
The app also displayed: “Windows setup didn’t finish — Try Windows setup again.”

This appears to be a repeatable project/thread indexing or Windows↔WSL path-association bug rather than actual data deletion.

I can reproduce this, and I think the underlying problem is broader than path normalization.

Environment:

Codex Desktop 26.721.11231.0
Windows 10.0.26300.8935
WSL 2.6.3.0
Session CLI 0.146.0-alpha.3.1

Reproduction:

Start a task while Agent Environment is set to WSL.
Its persisted first-turn context uses:
/home/<wsl-user>/<project>
Switch Agent Environment to Windows.
Reopen or continue that same existing task.
The same task/session ID is retained, but a later turn context now uses:
C:\home\<wsl-user>\<project>
The Windows backend rejects that path as invalid.

The app therefore preserves the conversation identity while silently changing the execution host and path semantics underneath it. Some old tasks appear to continue while others fail, making the behavior effectively nondeterministic.

This cost me an entire afternoon. The UI presents Agent Environment as a simple global choice, but gives no warning that it also changes how existing tasks are resumed.

Expected behavior:

Pin every existing task to the host/agent and canonical working directory used when it was created.
Apply an environment change only to newly created tasks, or explicitly require creating/forking a new task.
Keep Windows and WSL configuration, state, and task scopes isolated by default.
Show the active execution host and canonical working directory on each task.
Model WSL as a separate local/SSH-like host instead of a global toggle that retroactively affects old tasks.

This is not merely a malformed C:\home path. It is also a task-isolation and lifecycle bug: a task can retain its conversation history while its execution environment changes underneath it.

I can provide sanitized session metadata and logs if helpful.

Adding a current Windows + WSL datapoint with a deterministic resume failure and state evidence.

Environment

Codex Desktop (Microsoft Store): 26.803.10989.0
Windows 11 + WSL2, Ubuntu
Saved project root in Desktop: \\wsl$\Ubuntu\home\<wsl-user>
The affected task was originally associated with that WSL project.
Trigger: switching Agent environment from WSL to Windows for an A/B terminal test, then restarting the app. The integrated terminal setting was later changed to WSL, while the Agent environment remained Windows.

Failure

The existing task remains visible and its history can be read, but submitting any follow-up fails immediately with:

Invalid request: AbsolutePathBuf deserialized without a base path

The same failure is reproducible through the Desktop thread-continuation API, so it is not specific to the composer UI.

Persisted-state evidence

The saved project definition remained correct:

\\wsl$\Ubuntu\home\<wsl-user>

However, the affected row in the Windows-side %USERPROFILE%\.codex\state_5.sqlite contained:

threads.cwd = C:\home\<wsl-user>

That Windows path does not exist. A newly created healthy task for the same location used the canonical Windows UNC representation:

\\?\UNC\wsl$\Ubuntu\home\<wsl-user>

I made a native SQLite backup and atomically updated only the affected active user-thread row from C:\home\<wsl-user> to the canonical UNC value. Desktop then listed the task with the correct \\wsl$\... cwd, but attempting to resume it still returned the same AbsolutePathBuf error without a full app restart.

This suggests two coupled problems:

The Windows/WSL environment switch persists a mechanically translated, invalid C:\home\... cwd even though the saved project authority still has the correct WSL UNC root.
Correcting threads.cwd alone does not rebuild all base-path context needed to resume the task; an in-process cache or another per-session/path field remains stale.

Expected behavior

Existing tasks should remain pinned to the environment and canonical cwd under which they were created, or an environment change should require an explicit fork/new task.
WSL /home/... must never be persisted as Windows C:\home\....
Resuming should derive the execution cwd from the task's canonical project/environment identity rather than silently reinterpreting it under the newly selected global Agent environment.
If restoration cannot resolve a base path, the UI should report which stored path/context is invalid instead of exposing the internal serde error.

This matches the environment-switch lifecycle described in the existing comments, and adds a current-version reproduction plus the exact AbsolutePathBuf resume failure and row-level state comparison.

Follow-up with the exact failure layer after further read-only inspection.

The earlier threads.cwd repair was not blocked by an in-process cache. The Windows-side persistent logs contain the exact recorder error:

codex_rollout::recorder: failed to parse rollout line: AbsolutePathBuf deserialized without a base path

The affected rollout JSONL is internally consistent with the environment in which it was created:

session_meta: 1 record
turn_context: 8 records
every typed cwd/path in those records uses native WSL path semantics such as /home/<wsl-user>/... and /mnt/c/...
there is no later Windows turn_context mixed into that JSONL

After switching the global Agent environment to Windows, the Windows backend attempts to deserialize those pre-existing WSL AbsolutePathBuf values and fails before model execution. Updating the Windows state_5.sqlite row from the invalid C:\home\<wsl-user> to the canonical \\?\UNC\wsl$\Ubuntu\home\<wsl-user> correctly repairs sidebar/project association, but cannot make the Windows rollout parser accept the WSL-serialized typed paths.

The same task ID remains present in the WSL-side state database and points to the same transcript under /mnt/c/Users/<windows-user>/.codex/sessions/.... This confirms that the transcript is not missing or corrupted; it is a cross-backend rollout-deserialization incompatibility.

Navigation Menu

Repository navigation

[Windows][WSL] Codex Desktop rewrites /home project paths as C:\home, loses project chat associations, and reports valid working directories as missing #28094

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Update: reproduced on a second machine

Comment for openai/codex issue #28094

Environment

What happens

User-visible impact

Local state evidence

Cleanup attempts already tried

Workaround

Expected behavior

Environment

Failure

Persisted-state evidence

Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows][WSL] Codex Desktop rewrites /home project paths as C:\home, loses project chat associations, and reports valid working directories as missing #28094

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jun 13, 2026

bmccall17 commented on Jun 13, 2026

Update: reproduced on a second machine

AnhLead commented on Jun 13, 2026

kovachinfo commented on Jun 14, 2026

Rogier1977 commented on Jun 14, 2026

aidev2007 commented on Jun 14, 2026

Comment for openai/codex issue #28094

Environment

What happens

User-visible impact

Local state evidence

Cleanup attempts already tried

Workaround

Expected behavior

yunyunFlow commented on Jun 14, 2026

yunyunFlow commented on Jun 14, 2026

slugmandrew commented on Jun 15, 2026

Mistaxe commented on Jun 15, 2026

anonymuse commented on Jun 15, 2026

cowboycodr commented on Jun 15, 2026

RSchmeitz commented on Jun 15, 2026

AnhLead commented on Jun 16, 2026

slugmandrew commented on Jun 17, 2026

croc81 commented on Jun 17, 2026

mxmerce commented on Jun 17, 2026

zhaobenny commented on Jun 18, 2026

yui-stingray commented on Jun 21, 2026

BorisSavage commented on Jun 29, 2026

haitambelarche commented on Jul 22, 2026

FinalVar commented on Jul 31, 2026

fenicottero-loriot commented on Aug 11, 2026

Environment

Failure

Persisted-state evidence

Expected behavior

fenicottero-loriot commented on Aug 11, 2026

Rogier1977 commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions