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

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

• #28086
• #27553
• #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:

• #21147 — fresh WSL threads start with PowerShell and C:\home\...
• #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:

https://github.com/openai/codex/issues/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:

1. Fully quit Codex first, otherwise the running process may rewrite stale state back to disk.
2. Back up %USERPROFILE%\.codex.
3. 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.
4. 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.
5. 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.

1. 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.

1. Restore only the safe history files/folders, such as sessions, archived_sessions, attachments, and session_index.jsonl.
2. 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.

<img width="557" height="68" alt="Image" src="https://github.com/user-attachments/assets/a7d002df-1d9d-4d41-9e22-6c6183e5c77d" />

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)

1. 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.

This looks like a path-identity split between the project authority and UI/runtime projections. A WSL project should keep one canonical identity, then derive display/native paths from it instead of rewriting /home/... into a Windows path and storing that as if it were the project root.

The state I would expect to persist is: project id, environment kind (wsl, windows, ssh, etc.), canonical POSIX root, resolved native display path, session ids attached to that root, and the normalization version that produced each projection. If normalization changes after an update, old sessions should be migrated or marked stale; they should not silently disappear under “No chats”.

I maintain Better Agent (https://github.com/ofekron/better-agent), where provider sessions need stable cwd/project identity across desktop, CLI, and child sessions for the same reason. If useful, a star helps other desktop-agent builders find it.