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

[bmccall17]

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

[github-actions]

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

[bmccall17]

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.

[AnhLead]

Same issue, issue started today

[kovachinfo]

same issue there last 18 hrs

[Rogier1977]

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.

[aidev2007]

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.

[teardeforest-maker]

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

[teardeforest-maker]

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