WSL migration failures expose opaque internal deserialization errors with no recovery guidance

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

26.727.6591.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 Pro, x64 Windows build 26200 WSL2 with Ubuntu 24.04.4

What issue are you seeing?

After changing the Codex execution environment from Windows-native execution to WSL2, existing chats fail with opaque internal errors such as:

AbsolutePathBuf deserialized without a base path

data did not match any variant of untagged enum PermissionProfileDe

These messages expose internal implementation types but provide no useful explanation or recovery guidance.

They do not tell the user:

• that the affected chat was created under Windows-native execution
• that it contains incompatible Windows path, shell, workspace-root, sandbox, or permission metadata
• which saved path or record failed
• whether the conversation history is still intact
• whether switching back to Windows-native execution is a possible fallback
• whether moving the chat to another project will rebind it
• whether "Continue in new chat" will preserve the broken state
• how to back up, migrate, or recover the chat
• where to find relevant diagnostic logs or session files

The error message makes a recoverable environment-compatibility problem appear like unexplained chat corruption.

What steps can reproduce the bug?

1. Open the Codex Windows app and configure it to use Windows-native execution.

1. Create a project using a Windows path such as:

D:\Projects\EOE

1. Create and use a chat in that project.

1. Change the Codex execution environment to WSL2 / Ubuntu.

1. Reopen the existing chat created under Windows-native execution.

1. Attempt to load, continue, or fork the chat.

1. Observe errors such as:

AbsolutePathBuf deserialized without a base path

data did not match any variant of untagged enum PermissionProfileDe

1. Right-click the chat and select "Copy working directory."

1. Observe a malformed path such as:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0/app/resources/D:\Projects\EOE

1. Move the chat to a valid WSL project or use "Continue in new chat."

1. Observe that the broken environment metadata is preserved, while the UI still provides no explanation or recovery instructions.

Affected session ID:

019fbee1-4ad9-75d0-8c6e-8b610eaf4799

What is the expected behavior?

Codex should detect that the chat was created under a different execution environment and display a user-facing compatibility error rather than an internal deserialization message.

The message should explain:

• that the chat was created using Windows-native execution
• that its saved environment metadata is incompatible with WSL
• that the conversation history is still present
• the previous working directory
• the current execution environment
• which recovery options are available

For example:

"This chat was created using Windows-native execution and contains environment settings that cannot be loaded under WSL.

Previous working directory:
D:\Projects\EOE

Current execution environment:
WSL2

Your conversation history is still available, but the chat must be migrated or reopened using its original Windows environment."

Codex should then offer actions such as:

• Reopen using Windows-native execution
• Back up the chat
• Migrate paths and permissions to WSL
• Select a new project and rebind the chat
• View technical diagnostics
• Open recovery documentation

The session ID and relevant diagnostic location should also be included.

Additional information

The affected local rollout JSONL file was inspected and found to contain:

• 171 total JSONL records
• 171 valid JSON records
• 0 invalid JSON records

The conversation content itself appears intact.

The failure is caused by incompatible environment metadata, including:

• cwd = D:\Projects\EOE
• shell = powershell
• Windows workspace roots
• Windows filesystem sandbox entries
• Windows permission-profile structures

Codex logged seven parsing errors while attempting to resume or fork the session under WSL.

A newly created chat in the same WSL project works correctly and reports:

Working directory: /mnt/d/Projects/PFOS
Shell: bash

This confirms that the failure is specific to legacy session metadata and should be detected and explained explicitly by the app.

The current internal error messages provide no actionable information and caused more than two hours of unnecessary troubleshooting.