›_ Codex Issues
Codex Issues / #23189

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

Open 💬 3 comments Opened May 17, 2026 by srbgd
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.40821

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

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

Client:

  • Codex app on Windows, using a WSL Ubuntu project

App/OS:

  • Codex app: 26.513.40821
  • Windows + WSL (Ubuntu)

Project:

  • Originally added via Linux path: /home/ubuntu/spec-kit

Issue summary:
After updating the Codex app, older chats for a WSL-based project are no longer associated with the project correctly. Opening the terminal from an old chat fails because the chat’s saved working directory becomes a malformed Windows path that concatenates the app resources directory with a \\wsl$\ UNC path.

Steps to reproduce:
1) Open Codex desktop on Windows.
2) Open/use a project located in WSL at: /home/ubuntu/spec-kit
3) After updating Codex, open an older chat from the same project via Search or “All chats”.
4) Observe the old chat appears in global history but not correctly under the project.
5) Open the terminal from that old chat.

Expected:

  • Older chats remain attached to the WSL project at /home/ubuntu/spec-kit
  • Terminal opens in /home/ubuntu/spec-kit

Actual:

  • Old chat shows: “Current working directory missing. This chat's working directory no longer exists.”
  • Terminal attempts to cd into:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0/app/resources/\\wsl$\Ubuntu\home\ubuntu\spec-kit

  • Fails with: bash: cd: ... No such file or directory

Working directory values observed:

  • New chat cwd: /home/ubuntu/spec-kit
  • Old chat cwd:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0/app/resources/\\wsl$\Ubuntu\home\ubuntu\spec-kit

Timing:

  • Started immediately after a recent Codex app update to 26.513.40821
  • Observed: 2026-05-17 (UTC)

Additional notes:

  • Looks like a Windows/WSL path normalization regression: \\wsl$\Ubuntu\home\ubuntu\spec-kit is being treated as relative to the app resources directory instead of resolved to /home/ubuntu/spec-kit.

What steps can reproduce the bug?

Feedback ID: 019e373b-c49d-7d73-8a33-06b1637c3a55

What is the expected behavior?

After update chats in WSL project remain attached to the project

Additional information

Following settings were enabled during project creation and update:

Agent environment: Windows Subsystem for Linux
Integrated terminal shell: WSL

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23126

Powered by Codex Action

simon-ami · 3 months ago

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.

mxmerce · 2 months ago

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.