Chats lost when switching between WSL and Windows VS Code (storage path mismatch). I diagnosed the root cause and a reliable workaround.

What version of the VS Code extension are you using?

0.4.35

What subscription do you have?

Enterprise

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When VS Code runs inside WSL the extension stores sessions in the WSL filesystem (e.g. /home/<user>/.codex/sessions or \\wsl.localhost\Ubuntu\home\<user>\.codex\sessions). When VS Code runs natively on Windows it looks in C:\Users\<user>\.codex\sessions. If you start a chat in a WSL session then later open VS Code natively the UI shows no history because it is reading the Windows path instead of the WSL path.

What steps can reproduce the bug?

Repro steps

1. Open VS Code with Remote - WSL (or launch from a WSL shell).
2. Start a Codex chat.
3. Close VS Code.
4. Reopen VS Code natively on Windows (not remote).
5. Open the Codex pane. Chat history is missing. Inspecting disk shows sessions are in the WSL path, not C:\Users\<user>\.codex\sessions.

What is the expected behavior?

When VS Code is opened either natively or via Remote-WSL the Codex extension must show the same session history. Sessions created in WSL should be visible when VS Code is later opened natively and vice versa. The extension should either use a single canonical storage path or automatically detect and migrate session files between WSL and Windows.

Additional information

Reproducible root cause: session files are stored on different filesystems depending on how VS Code is launched.

Observed paths:

• WSL (when VS Code runs remote): /home/<user>/.codex/sessions (accessible as \\wsl$\Ubuntu\home\<user>\.codex\sessions)
• Windows (when VS Code runs natively): C:\Users\<user>\.codex\sessions

I recovered sessions locally by copying from the WSL path to the Windows path.

Suggested quick fixes for maintainers:

1. Use a single canonical storage path independent of process environment.
2. If process is remote (WSL/SSH/Remote-Containers) transparently map/migrate session files to the native profile.
3. Provide a user setting to override storage directory.
4. Add an “import sessions” or migration step on first activation.