Repository navigation
Windows Codex Desktop WSL/Ubuntu mode broken + local sessions not shown after update #28523
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.609.71450
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
I am seeing two related issues after recent Codex Desktop Windows updates, but the most urgent one is the Ubuntu/WSL integration.
My main development environment is Ubuntu through WSL. My repositories are inside WSL, and Codex Desktop Windows previously needed to work with those WSL folders. Since the update, WSL mode has been broken or unstable, which blocks my normal workflow.
Main urgent issue: WSL / Ubuntu mode is broken
When WSL mode was enabled in Codex Desktop, the app failed to start or failed to locate the CLI.
Previous WSL-related error:
Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.
At one point, Codex Desktop also tried to use the packaged Windows binary from:
C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe
This caused access/permission issues because WindowsApps is protected.
I had to disable WSL mode temporarily just to make the desktop app start again, but this is not a real fix because my repositories and workflow are inside Ubuntu/WSL.
Secondary issue: local chats are not displayed in the sidebar
After the same update and recovery attempts, my Codex Desktop sidebar still only shows 2 chats, even though the local session files exist.
Current local state:
C:\Users\<USER>\.codex\sessions = 89 files
C:\Users\<USER>\.codex\archived_sessions = 0 files
I successfully unarchived all archived sessions:
codex unarchive: 72 success / 0 failures
However, Codex Desktop still does not show these chats in the UI/sidebar. The archived chats page says there are no archived chats, but the normal sidebar still only shows 2 chats.
Previous SQLite/database errors
After the update, I also got this error:
Codex cannot access its local database.
failed to initialize sqlite state runtime under C:\Users\<USER>\.codex
migration 1 was previously applied but has been modified
When clicking “Back Up and Rebuild”, Codex also failed because it tried to create a backup directory inside WindowsApps:
Recovery failed: EPERM: operation not permitted, mkdir 'C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__...\app\db-backups'
So I currently have two problems:
- Most urgent: Codex Desktop Windows cannot reliably work with Ubuntu/WSL anymore.
- The app does not reindex/display my existing local sessions even though the
.jsonlsession files are present.
What steps can reproduce the bug?
I cannot provide my private session files publicly, but these are the steps that led to the issue:
-
Use Codex Desktop on Windows with WSL/Ubuntu enabled.
-
Keep projects/repositories inside Ubuntu/WSL.
-
Update Codex Desktop from Microsoft Store to version
26.609.9530.0. -
Try to launch Codex Desktop with WSL mode enabled.
-
The app fails with:
Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex. -
Disable WSL mode so the desktop app can start.
-
After the update, the local SQLite database also fails with:
migration 1 was previously applied but has been modified
_. Click “Back Up and Rebuild”.
9. The rebuild fails because the app tries to write a backup inside WindowsApps:
```text
EPERM: operation not permitted, mkdir 'C:\Program Files\WindowsApps\OpenAI.Codex_...\app\db-backups'
```
-
Manually move aside broken SQLite files and let Codex recreate the SQLite folder.
-
Run
codex unarchiveon all archived sessions. -
codex unarchivesucceeds:72 success / 0 failures -
Confirm local session files exist:
C:\Users\<USER>\.codex\sessions = 89 files C:\Users\<USER>\.codex\archived_sessions = 0 files -
Open Codex Desktop again.
Actual result: the Desktop sidebar still only shows 2 chats, and WSL mode still cannot be used safely for my Ubuntu-based repositories.
I am not attaching my .codex folder, auth.json, or .jsonl session files because they contain private code, local paths, and conversation content.
What is the expected behavior?
The expected behavior is:
-
Codex Desktop Windows should work correctly with Ubuntu/WSL projects.
-
If WSL mode is enabled, Codex Desktop should either:
- correctly detect and use the Codex CLI installed inside Ubuntu/WSL, or
- correctly bridge to the WSL environment without trying to execute a WindowsApps binary from Linux/WSL.
-
Windows Desktop and WSL CLI should not corrupt or conflict with each other’s SQLite state database.
-
Codex Desktop should safely recover/rebuild its local SQLite state without trying to write backup files inside the protected
WindowsAppsinstallation directory. -
Codex Desktop should reindex and display existing local session files from:
C:\Users\<USER>\.codex\sessions -
If
codex unarchivesucceeds for archived sessions, the UI/sidebar should show those restored chats. -
The app should not show only 2 chats when 89 local session
.jsonlfiles exist and archived sessions are empty.
Additional information
- Is there a known fix coming for Codex Desktop Windows WSL/Ubuntu mode?
- Should Windows Desktop and WSL CLI use separate
CODEX_HOMEdirectories to avoid SQLite migration conflicts? - Is there a safe way to restore WSL mode without breaking the local SQLite state database?
- Is there a supported command to force Codex Desktop to reindex existing
.jsonlsessions fromC:\Users\<USER>\.codex\sessions? - Is the
Back Up and Rebuildbutton supposed to write backups insideWindowsApps? It currently fails withEPERM.
I can provide sanitized logs and screenshots, but I cannot publicly attach my .codex folder, auth.json, or session .jsonl files because they may contain private source code, repository paths, and conversation content.
Activity
github-actions commentedon Jun 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
wangchenxudev commentedon Jul 23, 2026
Hi, I encountered the same issue and found a workaround that resolved it in my case.
Codex Desktop had been installed on a non-system drive through the Microsoft Store. After uninstalling it and reinstalling the same version on the default system drive (C:), WSL mode started working normally. I did not need to reinstall Codex inside WSL or configure CODEX_CLI_PATH.
This may be caused by Codex Desktop not correctly handling the application path when the MSIX package is installed on a non-system drive.
I hope this is helpful. Please let me know whether reinstalling it on C: works for you as well—or whether the issue still persists afterward.
LiYang-cyber commentedon Jul 30, 2026
yes, same on C
LyonWu21 commentedon Aug 19, 2026
In Codex 26.814.41407, this issue still exists.
I solved this after I installed Codex on the system drive