Windows Codex + WSL project: older threads lose cwd and terminal tries to cd into malformed WindowsApps/app/resources/\\wsl$ path #23189

Activity

1. srbgd

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 17, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on May 17, 2026
3. github-actions commented on May 17, 2026

   

   github-actionsbot

   on May 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop corrupts local history on Windows: project sessions disappear and UTF-8 Chinese history becomes mojibake #23126

   Powered by Codex Action
4. simon-ami commented on May 18, 2026

   

   simon-ami

   on May 18, 2026

   More actions

   I’m seeing the same after rebooting Windows. My project-specific sessions disappeared from the project sidebar, but Search can still find and open them. When opened, the thread shows:

   Current working directory missing
   This chat's working directory no longer exists

   The project directory still exists normally in WSL. This looks like the same cwd/path normalization issue rather than deleted sessions.
5. mxmerce commented on Jun 13, 2026

   

   mxmerce

   on Jun 13, 2026 – with ChatGPT Codex Connector

   More actions

   I hit what looks like the same class of Windows + WSL path normalization/sidebar indexing regression after updating Codex in-app to 0.139.0.

   Environment

   • Windows Codex app
   • Codex CLI/app version observed: 0.139.0
   • Windows app build visible in local config/runtime env: 26.609.41114
   • runCodexInWindowsSubsystemForLinux = true
   • Integrated terminal shell: WSL
   • Main WSL project path:
     • Linux: /home/<user>/dev/brain
     • UNC: \\wsl.localhost\Ubuntu\home\<user>\dev\brain
     • Also opened with: \\wsl$\Ubuntu\home\<user>\dev\brain

   Symptoms

   After the update, this was not isolated to one project:

   • The Projects sidebar showed only older chats under projects.
   • Recent chats disappeared from the Projects sidebar across multiple projects.
   • The top-level Chats section was empty.
   • Search could still find and open the “missing” chats, so the thread data was not deleted.
   • Opened chats showed this banner:

   Current working directory missing
   This chat's working directory no longer exists
   

   Local investigation

   The data was still present locally:

   • Recent session JSONL files still existed under:
     • C:\Users\<user>\.codex\sessions
   • session_index.jsonl still listed the recent chats.
   • state_5.sqlite still contained the thread rows.

   The issue appeared to be path normalization/grouping in the local thread index. In state_5.sqlite, recent WSL-backed threads were keyed with mixed paths such as:

   /home/<user>/dev/brain
   C:\home\<user>\dev\brain
   

   But the visible project roots/sidebar entries were keyed with WSL UNC paths such as:

   \\wsl.localhost\Ubuntu\home\<user>\dev\brain
   \\wsl$\Ubuntu\home\<user>\dev\brain
   

   This made the chats searchable but not grouped correctly under Projects, and in some cases Codex tried to resolve a non-existent Windows path like:

   C:\home\<user>\dev\brain
   

   Workaround that restored the sidebar grouping

   After fully closing Codex, I backed up:

   C:\Users\<user>\.codex\state_5.sqlite*
   C:\Users\<user>\.codex\.codex-global-state.json*
   C:\Users\<user>\.codex\session_index.jsonl
   

   Then I updated the threads.cwd values in state_5.sqlite, mapping Linux/incorrect Windows paths back to the WSL UNC project paths. After reopening Codex, the recent chats appeared under Projects again.

   Remaining banner and workaround

   After repairing threads.cwd, the sidebar grouping was fixed, but the banner still appeared above opened chats:

   Current working directory missing
   This chat's working directory no longer exists
   

   That disappeared only after creating a Windows symlink so the mistaken Windows path pointed to the real WSL filesystem location:

   # Run after closing Codex; admin shell may be required.
   $target = "\\wsl.localhost\Ubuntu\home\<user>\dev"
   $link = "C:\home\<user>\dev"
   
   New-Item -ItemType Directory -Path (Split-Path $link) -Force | Out-Null
   New-Item -ItemType SymbolicLink -Path $link -Target $target
   Test-Path "C:\home\<user>\dev\brain"

   Once that returned True, reopening Codex removed the banner.

   Expected behavior

   • Updating Codex should not cause recent WSL-backed chats to disappear from Projects.
   • Codex should consistently normalize WSL project paths between:
     • /home/...
     • \\wsl.localhost\...
     • \\wsl$\...
   • Existing WSL project chats should not be remapped to non-existent Windows paths like C:\home\....

   Actual behavior

   • Recent chats were still searchable, but no longer grouped under Projects.
   • Codex showed “working directory missing” because it attempted to resolve a stale/non-existent Windows path.
   • The issue affected multiple recent projects/chats immediately after the update.

   This looks like a Windows app 0.139.0 / build 26.609.41114 WSL path normalization or sidebar indexing regression.
6. torba-lab commented on Oct 2, 2026

   

   torba-lab

   on Oct 2, 2026

   Last edited by torba-lab

   More actions

   Regression still present in Codex Desktop 26.930.2377.0.

   Current application path:
   C:\Program Files\WindowsApps\OpenAI.Codex_26.930.2377.0_x64__2p2nqsd0c76g0\app

   But Codex still generates:

   cd '/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0/app/resources/\wsl$\Ubuntu-24.04\home\user\torbaretail_audit'

   PowerShell then resolves this as:

   C:\mnt\c\Program Files\WindowsApps\OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0\app\resources\wsl$\Ubuntu-24.04\home\user\torbaretail_audit

   and fails with PathNotFound.

   The WSL workspace itself is healthy:

   wsl -d Ubuntu-24.04
   cd /home/user/torbaretail_audit
   pwd

   returns:

   /home/user/torbaretail_audit

   This suggests stale pre-update cwd/session metadata plus incorrect WSL UNC canonicalization.

   This also reproduces in a newly created chat in the same WSL project, so it is not limited to restoring an old conversation.

   There also appears to be an additional user-visible consequence of the same process-launch / workspace-path problem:

   If I send a new prompt to Codex as a file attachment (for example a text or Markdown attachment), Codex is unable to reliably read the attachment.

   It reports:

   "Local process launcher repeats transient CreateProcess: No such file or directory, so I will not make assumptions about the attachment contents."

   As a result I have to paste the exact same prompt directly into the chat as inline text. When pasted inline, Codex can read and follow it normally.

   So the failure appears to affect not only terminal execution, but also local attachment/file ingestion for WSL-based projects when the attachment needs to be accessed through the local workspace execution layer.

   I cannot confirm that the attachment problem has exactly the same root cause, but it is consistently correlated with the same CreateProcess / malformed WSL workspace-path failure.

   Observed on:

   • Codex Desktop 26.930.2377.0
   • Windows
   • WSL Ubuntu-24.04
   • Agent environment: Windows Subsystem for Linux
   • Integrated terminal shell: WSL