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

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:

1. Start a task while Agent Environment is set to WSL.
2. Its persisted first-turn context uses:

/home/<wsl-user>/<project>

1. Switch Agent Environment to Windows.
2. Reopen or continue that same existing task.
3. The same task/session ID is retained, but a later turn context now uses:

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

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

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

Suggested product behavior:

1. Persist the originating execution host/path dialect with each thread and pin existing threads to it.
2. Apply a global Agent environment change only to newly created threads, or require an explicit fork/migration.
3. If cross-host migration is supported, convert all typed path fields through a versioned migration rather than reinterpreting serialized AbsolutePathBuf records under the new host.
4. Surface the offending record/field and original environment instead of the raw serde error.

This looks like a good separation test between intact rollout data and broken Desktop project/path indexing. I’m field-testing codex-rescue==0.1.0a4 on persisted-session cases where chats remain on disk but the client loses their project association.

If one affected rollout is still available, could you try:

pipx install codex-rescue==0.1.0a4
codex-rescue sessions
codex-rescue doctor --json "/path/to/the-affected-rollout.jsonl"

It won’t repair the Windows↔WSL path mapping itself, but the read-only result can tell us whether the underlying persisted session is healthy or contains state/schema defects beyond the UI/index layer.

Please share only sanitized status/findings/aggregate counts—no raw rollouts, databases, prompts, tool output, credentials, repository data, session IDs, or private paths.